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 …

Beware the SST

In Percona XtraDB Cluster (PXC) I often run across users who are fearful of SSTs on their clusters. I’ve always maintained that if you can’t cope with a SST, PXC may not be right for you, but that doesn’t change the fact that SSTs with multiple Terabytes of data can be quite costly.

SST, by current definition, is a full backup of a Donor to Joiner.  The most popular method is Percona XtraBackup, so we’re talking about a donor node that must:

1. Run a full XtraBackup that reads its entire datadir
2. Keep up with Galera replication to it as much as possible (though laggy donors don’t send flow control)
3. Possibly still be serving application traffic if you don’t remove Donors from rotation.
…

The Percona version of MySQL has been such a good replacement for the generic MySQL version that many of the features and options that existed in Percona have been merged into the generic MySQL. Innodb_fast_checksum was an option added to … Continue reading →

I've written two separate posts about the MySQL 5.6 temporal column format change, but I haven't yet addressed the problem with the way this upgrade was implemented. Essentially, the problem is that the implicit format upgrade causes a write-blocking full table rebuild the first time you run ALTER TABLE after upgrading, even if the ALTER TABLE command is an online DDL operation that normally doesn't block writes.

This behavior is well intentioned, but harmful. The intent is for the server to tack on a seemingly innocuous column format upgrade to my existing ALTER TABLE command, but when it changes my DDL from non-blocking …

In the MySQL team, we have been working really hard on refactoring the optimizer and improving the cost model. The hacks of storage engines lying to the optimizer are being rolled back, and your chances of getting an optimal query plan should now be much higher than in prior releases of MySQL.

The optimizer team has also allowed cost constants to be configurable on both a server and a storage engine basis, and we are confident that the default InnoDB engine will always work “as good as MyISAM” (which has a natural advantage, in that the optimizer was originally largely built around it.)

Today, I want to issue a challenge:

Find an example where the …

We are pretty much raving fans of CircleCI and we are not ashamed to say it. Here’s why.

What Does CircleCI Do For Us?

It would be reasonable to describe CircleCI like this:

• continuous integration and testing
• compiles our code for us
• automated QA

But that misses the point, because what they really do is they help us delight our customers. And they don’t just provide tools or ingredients or recipes for this. They provide a solution. I know it’s a buzzword and I have avoided saying “solution” since back in the day when I was a .NET developer using Visual Studio. But it is the only word that describes what CircleCI does for us.

We have a hard challenge/problem: in order to provide the absolute best service for our customers, we must be able to ship improvements in minutes with confidence. …