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. …

Using MySQL Enterprise Monitor with the MySQL Enterprise Firewall

Using MySQL Enterprise Monitor 3.0.22, the following newly added variables for the MySQL Enterprise Firewall are added : Ref :  http://dev.mysql.com/doc/relnotes/mysql-monitor/3.0/en/news-3-0-22.html

• System Variables:
  
  • mysql_firewall_max_query_size
  • mysql_firewall_mode
  • mysql_firewall_trace
• Status Variables:
  
  • Firewall_access_denied
  • Firewall_access_granted
  • Firewall_cached_entries

For information about MySQL Enterprise Firewall, you can refer to the information on Web  …

State Snapshot Transfer (SST) is a way for Galera to transfer a full data copy from an existing node (donor) to a new node (joiner). If you come from a MySQL replication background, it is similar to taking a backup of a master and restoring on a slave. In Galera Cluster, the process is automated and is triggered depending on the joiner state.

SST can be painful in some occasions, as it can block the donor node (with SST methods like mysqldump or rsync) and burden it when backing up the data and feeding it to the joiner. For a dataset of a few hundred gigabytes or more, the syncing process can take hours to complete - even if you have a fast network. It might be advisable to avoid e.g. when running in WAN environments with slower connects and limited bandwidth, or if you just want a very fast way of introducing a new node in your cluster.

…