MySQL 5.7 introduced the LOGICAL_CLOCK type of multi-threaded slave (MTS).  When using this type of parallel replication (and when slave_parallel_workers is greater than zero), slaves use information from the binary logs (written by the master) to run transactions in parallel.  However, enabling parallel replication on slaves might not be enough to get a higher replication throughput (VividCortex

I have a new blog post on blog.booking.com describing MariaDB 10.1 Optimistic Parallel Replication (with benchmark results):

Evaluating MySQL Parallel Replication Part 4: More Benchmarks in Productionhttp://blog.booking.com/evaluating_mysql_parallel_replication_4-more_benchmarks_in_production.html

If you want to know more about MySQL/MariaDB Parallel Replication and if you are attending 

I am very happy that my talk, MySQL Parallel Replication: inventory, use-cases and limitations, is included in the Sneak Peek of Percona Live Amsterdam.  As a member of the Conference Committee, I knew this was being discussed, but I refrained from commenting on discussion about my talk and the submissions of my colleagues from Booking.com.

Mentioning the conference committee, as you can guess,

In a few days, I will be flying to San Francisco and then making my way to Santa Clara to attend the Percona Live Conference.  On the last day of the conference (Thursday), I will speak about MySQL Parallel Replication.  I hope to see you there and I will he happy to answer questions you might have (on this subject and others):

Thursday at 12:50 pm: MySQL Parallel Replication: inventory,

Reminder: MTS = Multi-Threaded Slave.

Update 2017-04-17: since the publication of this post, many things happened:

the procedure for fixing a crashed slave has been automated (Bug#77496) Bug#80103 as been closed at the same time as Bug#77496 but I still think there are unfixed things, see Bug#81840

End of update 2017-04-17.

I will be talking about parallel replication at FOSDEM in Brussel on

This year, Percona introduced Community Voting for Percona Live submission.  This is what you can read on the conference website:

In an effort to involve the larger community in the selection of speaking sessions for the 2016 Percona Live Data Performance Conference, we’ve implemented a community voting process. After a speaker submits a proposal we encourage sharing to the community and social

My latest post is online on the Booking.com blog: Evaluating MySQL Parallel Replication Part 3: Benchmarks in Production.  In this post, I present benchmark results on MariaDB 10.0 parallel replication on four Booking.com production workloads.

This post is also the opportunity to promote my two talks at Percona Live Europe, taking place in Amsterdam from September 21 to 23:

Binlog Servers at

http://blog.booking.com/evaluating_mysql_parallel_replication_2-slave_group_commit.html

Follow the link above to read my latest article on the Booking.com developer blog.  It is about MySQL Parallel Replication and a very nice side effect of the MariaDB implementation: Slave Group Commit.

This is also a good opportunity to remind you that I will speak at Percona Live Santa Clara 2015 about 

http://blog.booking.com/better_parallel_replication_for_mysql.html

Follow the link above to read my latest article on the Booking.com developer blog.  It is about MySQL Parallel Replication and Binlog Servers.

This fulfills my promise made at Percona Live London 2014 during my talk High Availability, Disaster Recovery and Extreme Read Scaling using Binlog Servers: I finally took the time to

Multi-threaded replication is a new feature introduced in MySQL 5.6 and MariaDB 10.0. In traditional single-threaded replication, the slaves have a disadvantage as they have to process in sequence what a master executed in parallel. This, plus the fact that slaves usually have a lot of read-only connections to deal with as well, can easily create performance problems. That is, a single-threaded slave needs to be set to allow fewer connections, otherwise there’s a higher risk of it not being able to keep up with the replication stream. There is no exact rule for this, as it relates to general I/O capacity and fsync latency, as well as general CPU and RAM considerations and query …