By default, for every client connection the MySQL server spawns a separate thread which will process all statements for this connection. This is the ‘one-thread-per-connection’ model. It’s simple and efficient until some number of connections N is reached. After this point performance of the MySQL server will degrade, mostly due to various contentions caused by N threads that are trying to access shared resources: either system ones like CPU, IO, memory or MySQL specific: structures/locks/etc. To keep the system stable and avoid degradation in the performance we need to limit the number of active threads, and at the same time we do not want to limit number of the client connections. The ‘Thread Pool’ model helps us to achieve that. It allows mapping N client connections to M number of active threads (actually performing work) while demonstrate a smooth and stable throughput for the MySQL server.

There are several implementations of …

Percona Server version 5.5.35-33.0

Percona is glad to announce the release of Percona Server 5.5.35-33.0 on December 20th, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.35, including all the bug fixes in it, Percona Server 5.5.35-33.0 is now the current stable release in the 5.5 series. All of Percona‘s software is open-source and free, all the details of the …

I recently conducted a test backup of my “master-slave” setup in my VirtualBox as I was migrating from Percona Server 5.6.12 to version 5.6.13-rel61.0 with Percona XtraBackup v2.2.0 rev. 4885. However, doing the backup on my slave, I encountered this problem:

[04] Compressing and streaming ./test/checksum.ibd
[01] Compressing and streaming ./mysql/slave_master_info.ibd
Assertion "to_read % cursor->page_size == 0" failed at fil_cur.cc:293
innobackupex: Error: The xtrabackup child process has died at /usr/bin/innobackupex line 2641.

This is related to a bug posted by my colleague George  …

Recently, I helped a client that was having issues with deployments causing locking in their production databases.  At a high level, the two key components used in the environment were:

• Capistrano (scripted deployments) [website]
• Liquibase (database version control) [website]

At a high level, they currently used a CLI call to Liquibase as a sub-task within a larger deployment task.  The goal of this engagement was to modify that sub-task to run Liquibase in a non-blocking fashion as opposed to the default that just runs native ALTERS against the database.

As I wasn’t very familiar with Liquibase, I took this opportunity to learn more about it and it seems like a very valuable tool.  Essentially, it does the following:

• Adds two version control tables to …

8PM. One of the servers found a critical bug. Hop online and discuss, log bug. 10PM. Patch ready. 10:30PM. New build ready. 10:45PM. New RQG run initiated. This was by no means an uncommon sight during the months of testing that went into Percona Server 5.6, in fact it was commonplace.

At a certain point, we had 3 very high end servers (modern cpu’s, heaps of cores and memory), all equipped with either fast SSD’s or Fusion-io flash storage, executing thousands of trials, 8 in parallel per server, each executing 1 to 25 mysql threads per running mysqld instance.

And that was just the final months of testing. Before that much work was done on finding “every last bug out there”. We discovered many bugs in both upstream (Oracle’s MySQL 5.6) and in Percona Server 5.6. I personally logged around 100 bugs, but the total count would be much higher still.

My colleague …

Percona Server has implemented per-query variable statement support in version 5.6.14-62.0. This feature provides the ability to set variable values only for a certain query, after execution of which the previous values will be restored. Per-query variable values can be set up with the following command:

mysql> SET STATEMENT <variable=value> FOR <statement>;

Example:

If we want to increase the sort_buffer_size value just for one specific sort query we can do it like this:

mysql> SET STATEMENT sort_buffer_size=100000 FOR SELECT name FROM name ORDER BY name;

Using the per-query variable statements with …

In MySQL 5.6 InnoDB has a dedicated thread (page_cleaner) that’s responsible for performing flushing operations. Page_cleaner performs flushing of the dirty pages from the buffer pool based on two factors:
- access pattern  -  the least recently used pages will be flushed by LRU flusher from LRU_list when buffer pool has no free pages anymore;
- age – the oldest modified non-flushed pages are part of flush_list structure and will be flushed by flush_list flusher based on several heuristics.

There is a good overview of the page_cleaner and also here you may find some details about flushing in MySQL 5.6. Below I describe several additional aspects of the flush_list flushing that was not really …

Percona Server version 5.5.34-32.0

Percona is glad to announce the release of Percona Server 5.5.34-32.0 on October 28th, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.5.34, including all the bug fixes in it, Percona Server 5.5.34-32.0 is now the current stable release in the 5.5 series. All of Percona‘s software is open-source and free, all the details of the …

Percona Server version 5.1.72-14.10

Percona is glad to announce the release of Percona Server 5.1.72-14.10 on October 28th, 2013 (Downloads are available here and from the Percona Software Repositories). Based on MySQL 5.1.72, including all the bug fixes in it, Percona Server 5.1.72-14.10 is now the current stable release in the 5.1 series. All of Percona‘s software …

Percona Server version 5.6.14-62.0

Percona is glad to announce the release of Percona Server 5.6.14-62.0 on October 24th, 2013 (Downloads are available here and from the Percona Software Repositories.

Based on MySQL 5.6.14, including all the bug fixes in it, Percona Server 5.6.14-62.0 is the current GA release in the Percona Server 5.6 series. …