The MySQL manual says

--socket=file_name, -S file_name ... On Unix, the name of the Unix socket file to use, for connections made using a named pipe to a local server.
The default Unix socket file name is /tmp/mysql.sock.

which might surprise folks who've had to contend with the error message
"Can't connect to local MySQL server through socket '[something-other-than-/tmp/mysql.sock]'".

I'll try to explain here why the name is often something quite different, how to know what the MySQL server is really listening for, what the fixes are for either users or application developers, and why it still matters.

Why the name is not always /tmp/mysql.sock

First, the Linux Foundation publishes a document "Filesystem Hierarchy Standard". Version 2.3 says …

Thanks for writing this. I have filed https://bugs.launchpad.net/percona-server/+bug/1475955 to improve ours docs as well.

[…] innodb_fast_checksum=1 and upgrading to MySQL 5.6 […]

Yet again, this log buffer edition brings some rich blog posts from Oracle, SQL Server and MySQL.

Oracle:

• Installing Oracle XE, ORDS and Apex on CentOS
• Major Growth is Expected in the DBaaS Space. Are Your Skills Ready?
• How to Hide Actions in OBPM 12c Workspace
• You can configure auto refresh for ADF BC cached LOV and this works out of the box, no special coding is needed.
• Search and …

Fri, 2015-07-17 07:47diptijoshi

In the last two releases of MariaDB Enterprise, we have provided enhanced performance with the introduction of certified MariaDB binaries for POWER8 and optimized binaries for the x86 platform. This Summer we make it more efficient and automated for developers and DBAs to use our high performance MariaDB binaries.

Ease of Use

MariaDB Enterprise now comes with Docker images as well as Chef recipes and cookbooks so developers can now easily deploy and run their database applications. Using Docker images from the MariaDB Enterprise repository,

• you …

As part of the release of MySQL-5.7.7, based on community feedback, improvements have been made with respect to replication defaults, which will make MySQL replication safer and easier to use.

This blog is intended to provide information about these default changes, and it briefly explains the advantages of having them.

1) Enable Simplified GTID recovery by default:

binlog_gtid_simple_recovery=TRUE by default.
https://dev.mysql.com/doc/refman/5.7/en/replication-options-gtids.html#sysvar_binlog_gtid_simple_recovery

This variable controls how binary log files are iterated during the search for GTIDs when MySQL starts or restarts.

Setting this option to TRUE gives improved recovery performance. Because of this option server startup and binary log purge …

[…] PlanetMySQL Voting: Vote UP / Vote DOWN Full article:innodb_fast_checksum=1 and upgrading to MySQL 5.6 […]

Recently I tested several different MySQL upgrade scenarios for the blog posts I wrote about the temporal format upgrade. This required me to create a bunch of tables with datetime/timestamp/time columns in MySQL 5.5 and then physically copy those tables to a MySQL 5.6 or 5.7 database. I created 4 copies of each table to test out InnoDB versus MyISAM and partitioned tables versus non-partitioned tables. MySQL Sandbox made the process easy.

These are the MySQL versions I wanted to test:

• 5.5.34
• 5.6.15
• 5.6.22
• 5.6.25
• 5.7.7

I was able to download the latest 5.6 and 5.7 releases here and the older releases here.

Read on for an overview of the MySQL …

In my previous post, I used incremental backups in Percona XtraBackup as a method for rebuilding a Percona XtraDB Cluster (PXC) node without triggering an actual SST. Practically this reproduces the SST steps, but it can be handy if you already had backups available to use.

In this post, I want to present another methodology for this that also uses a full backup, but instead of incrementals uses any binary logs that the cluster may be producing.

Binary logs on PXC

Binary logs are not strictly needed in PXC for replication, but …

Recently we got request from our customer that something is going wrong with their database and they’re are getting strange errors after each insert or update to specific table. The strangeness caused by “Unknown column ‘column-name’ in ‘field list'” message while this column was existing in this table. Our investigation shown that this was caused by trigger on the table they were trying to do the insert/update. This trigger did the insert to another table where the mentioned column didn’t exist.

Let me show you example:

create test DB and 2 test tables:

create database test;
use test;

create table t1 (field1 int auto_increment not null, field2 varchar(10), field3 varchar(10), primary key(field1)) engine=innodb;
create table t2 (field1 int, field2 varchar(10)) engine=innodb;

Then create a new insert trigger on t1 table:

delimiter ##

create trigger insert_on_t1_to_t2
 after insert
 on t1 for each …