Database replication is still interesting after all these years.  Two of my talks focused on replication technology were accepted for the upcoming MySQL 2010 Conference.  Here are the summaries.

• Clustering for the Masses - A Gentle Introduction to Tungsten for MySQL 

• Not Your Grandpa’s Replication-The New Wave of MySQL Replication and How It Helps Your Applications

The first talk is a solo presentation covering Tungsten, which creates highly available and scalable database clusters using vanilla MySQL databases linked by flexible …

I have been talking about this for a while, now at last I have found the time to get started! Below is a picture from my 2008 MySQL User Conference presentation. It illustrates how engine level replication works, and also shows how this can be ramped up to provide a multi-master HA setup.


What I now have running is the first phase: asynchronous replication, in a master/slave configuration. The way it works is simple. For every slave in the configuration the master PBXT engine starts a thread which reads the transaction log, and transfers modifications to a thread which applies the changes to PBXT tables on the slave.

Where to get it

I have pushed the changes that do this trick to PBXT 2.0 on Launchpad. The branch to try out is …

As I've been doing the last couple of years, I will be going to the O'Reilly MySQL Conference & Expo. In addition to the tutorial and the replication sessions that I will be holding together with Lars, I will be holding a session about the binary log together with Chuck from the Backup team which the Replication team normally works very close with.

This year, O'Reilly also have a Friend of the Speaker discount of 25% that you can use when you register using the code mys10fsp.

The sessions that we are going to hold are listed below. Note that I am using Microformats, which will allow …

I have recently been trying out semisynchronous replication. This is a new feature added in MySQL 5.5 based on the original google patch.

Installing was very simple and has been covered elsewhere in detail. Suffice to say it was relatively simple to do.

While test I was a bit surprised by some behavior I saw that turned out correct. What I wanted to examine what was semi-synchronous actually does and use cases for it.

The manual defines this feature correctly in very careful language:
If semisynchronous replication is enabled on the master side and there is at least one semisynchronous slave, a thread …

This Thursday (February 11th, 14:00 UTC), Seppo Jaakola & Alex Yurchenko will talk about MySQL Galera Multi-Master Replication. Galera provides synchronous multi-master replication and uses a certification-based replication method for replicating transaction write sets in a DBMS cluster. The replication method requires close co-operation with database transaction processing and DMBS must support a specific replication API to be compatible with Galera. Codership has integrated Galera replication in the InnoDB storage engine, and the resulting MySQL/Galera cluster product has been published as a production-ready GA release in December 2009. The MySQL/Galera release 0.7 is available on the Codership and …

This Thursday (February 11th, 14:00 UTC), Seppo Jaakola & Alex Yurchenko will talk about MySQL Galera Multi-Master Replication. Galera provides synchronous multi-master replication and uses a certification-based replication method for replicating transaction write sets in a DBMS cluster. The replication method requires close co-operation with database transaction processing and DMBS must support a specific replication API to be compatible with Galera. Codership has integrated Galera replication in the InnoDB storage engine, and the resulting MySQL/Galera cluster product has been published as a production-ready GA release in December 2009. The MySQL/Galera release 0.7 is available on the Codership and …

This Thursday (February 11th, 14:00 UTC), Seppo Jaakola & Alex Yurchenko will talk about MySQL Galera Multi-Master Replication. Galera provides synchronous multi-master replication and uses a certification-based replication method for replicating transaction write sets in a DBMS cluster. The replication method requires close co-operation with database transaction processing and DMBS must support a specific replication API to be compatible with Galera. Codership has integrated Galera replication in the InnoDB storage engine, and the resulting MySQL/Galera cluster product has been published as a production-ready GA release in December 2009. The MySQL/Galera release 0.7 is available on the Codership and …

In case you have not noticed, MariaDB is joining the list of projects thinking about how to improve MySQL replication.   The discussion thread starts here on the maria-developers mailing list.

This discussion was jointly started by Monty Program, Codership, and Continuent (my employer) in an effort to push the state of the art beyond features offered by the current MySQL replication.  Now that things are starting to die down with the Oracle acquisition, we can get back to the job of making the MySQL code base …

Release 1.2.2 of Tungsten Clustering is available on SourceForge as well as through the Continuent website.  The release contains mostly bug fixes in the open source version but there are also two very significant improvements of interest to all users.

• The manager and monitoring capabilities of Tungsten are completely integrated on the same group communications channel.  This fixes a number of problems that caused data sources not to show up properly in older versions.  
• We are officially supporting a new Tungsten Connector capability for MySQL called pass-through mode, which allows us to proxy connections by transferring network blocks directly rather than translating native request protocol to JDBC calls.  Our tests show that it speeds up throughput by as much as 200% …

I generally thought about MySQL replication as being quite low overhead on Master, depending on number of Slaves. What kind of load extra Slave causes ? Well it just gets a copy of binary log streamed to it. All slaves typically get few last events in binary log so it is in cash. In most cases having some 10 slaves are relatively low overhead not impacting master performance a lot. I however ran into the case when performance was significantly impacted by going from 2 to 4 slave on the box. Why ?

The reason was Master was having a lot of very small updates going on - over 15.000 transactions a second. Each time event is logged to the binary log all 4 threads feeding binary logs to the slave were to be woken up to send the update notification. With 4 slaves connected this makes 60.000 of threads being woken up sending some 60.000 packets (there may be some buffering taking place on TCP side merging multiple sends but still)

I guess …