With the recent release of Percona XtraDB Cluster, I am increasingly being asked about MySQL’s semi-synchronous replication. I find that there are often a number of misconceptions about how semi-synchronous replication really works. I think it is very important to understand what guarantees you actually get with semi-synchronous replication, and what you don’t get.

The first thing to understand is that despite the name, semi-synchronous replication is still asynchronous. Semi-synchronous is actually a pretty bad name, because there is no strong coupling between a commit on the master and a commit on the replicas. To understand why, let’s look at what truly synchronous replication means. In truly synchronous replication, when you commit a transaction, the commit does not complete until all replicas have also committed successfully. …

Backing up binary logs are essential part of creating good backup infrastructure as it gives you the possibility for point in time recovery. After restoring a database from backup you have the option to recover changes that happend after taking a backup. The problem with this approach was that you had to do periodic filesystem level backups of the binary log files which could still lead to data loss depending on the interval you back them up.
Recently in MySQL 5.6, mysqlbinlog got a new feature addition that supports connecting to remote MySQL instances and dumping binary log data to local disks ( http://dev.mysql.com/doc/refman/5.6/en/mysqlbinlog-backup.html ). This can be used as a foundation of our live binary log backups.

The wrapper script below will connect to the remote server specified in the config and ensure mysqlbinlog utility …

In our recent release of Percona Server 5.5.19 we introduced new value for innodb_flush_neighbor_pages=cont.
This way we are trying to deal with the problem of InnoDB flushing.

Actually there is also the second fix to what we think is bug in InnoDB, where it blocks queries while it is not needed (I will refer to it as “sync fix”). In this post I however will focus on innodb_flush_neighbor_pages.

By default InnoDB flushes so named neighbor pages, which really are not neighbors.
Say we want to flush page P. InnoDB is looking in an area of 128 pages around page P, and flushes all the pages in that area that are dirty. To illustrate, say we have an area of memory like …

There and in coming posts I am going to cover main features of Percona XtraDB Cluster. The first feature is High Availability.

But before jumping to HA, let’s review general architecture of the Percona XtraDB Cluster.

1. The Cluster consists of Nodes. Recommended configuration is to have at least 3 nodes, but you can make it running with 2 nodes too.
2. Each Node is regular MySQL / Percona Server setup. The point is that you can convert your existing MySQL / Percona Server into Node and roll Cluster using it as base. Or otherwise – you can detach Node from Cluster and use it as just a regular server.
3. Each Node contains the full copy of data. That defines XtraDB Cluster behavior in many ways. And obviously there are benefits and drawbacks.

Benefits of such approach:

…

I understand that the new technology can be scaring and this makes entry barriers to try and get familiar with it.
That’s why I created simple set of scripts which setup N nodes cluster on running EC2 instances.

The script assumes that you have running N EC2 instances (in the same availability zone) running RedHat Enterprise Linux 6.2 64bit (I use m1.xlarge size).

You put hostnames of the instances into ec2hosts.txt file and run install.nodes.sh script.
You also should have your private key to access to your instances (test-cluster.pem in my case).

For my box installing and starting 3 nodes took exactly

time install.nodes.sh
...
real    2m51.257s

In fact you can deploy as many nodes as you want, I made also running 20 nodes cluster.

After that you have the cluster deployed and ready to accept queries!

The scripts are …

In this post I want to show new possibilities which open with Percona XtraDB Cluster.
We will create 3 nodes Cluster with nodes on different continents (Europe, USA, Japan) and each node will accept write queries.
Well, you theoretically could create 3 node traditional MySQL ring replication, but this is not what you want to use day-to-day.

To show how it works I will use Amazon m1.xlarge instances, by one in Tokyo, Ireland and North California, running RedHat Entreprise 6.2 64bit.

In fact to create instances is most time consuming task. After that using my script you will have cluster running in 5 min or less.

There however some precautions needed if you run Amazon instances.
First, you need to open ports in the firewall. For the communication the nodes need, …

You probably saw that Vadim blogged about the first alpha release of Percona XtraDB Cluster. Just in time: now I can talk about it at my High Availability talk in Percona Live DC! If you’re coming, be sure to catch us in the hallway and ask those specific questions that won’t be addressed in a general survey talk on HA solutions.

Preparing Choosing Storage Systems for MySQL talk for Percona Live in Washington,DC I ran into great paper called Sane SAN 2010 by James Morle from Scale Abilities – and Oracle consulting company. It is worth to read for variety of reason yet for this post I wanted to mention what James calls “Busy” Oracle database application when it comes to IO consumption:

It is applications either using Over 10.000 IOs Per second (latency sensitive) or using Over 500MB/s bandwidth (bandwidth sensitive). I wonder how many of MySQL Users are running applications of these scale, for single …

I got a question a while ago about how Percona Server handles corrupted data more gracefully than the standard MySQL server from Oracle. The short version is that it won’t crash the whole server.

With standard MySQL from Oracle, if any page of data in InnoDB is found to be corrupt, the entire instance will crash forcefully. This is a good policy if you want to treat your entire data set as a single unit, which is either usable or not. However, this does not reflect reality for many users, who have a lot of data collocated in a single instance. In such cases, it is desirable for the server to continue running, so the corruption in one database does not affect the others.

Percona Server handles corruption more gracefully, if you enable it, by simply marking the single table as corrupt, and not crashing the entire server.

The relevant documentation is …

One thing I noticed during the observation was that there were roughly 2,000 new connections to MySQL per second during peak times. This is a high number by any account.

When a new connection to MySQL is made, it can go into the back_log, which effectively serves as a queue for new connections on operating system size to allow MySQL to handle spikes. Although MySQL connections are quite fast compared to many other databases it can become the bottleneck. For a more in depth discussion of what goes on during a connection and ideas for improvement, see this post by Domas]),

With MySQL 5.5 default back_log of 50 and 2000 connections created per second it will take just 0.025 seconds to fill the queue completely if requests are not …