MySQL 8.0.1 Replication Performance Improvements

存储架构 2017-04-29

MySQL 8.0.1 introduces new features and improvements to replication. The next sections summarize some related to performance.

1. WL#9556 – Writeset-based dependency tracking on the master

Transaction writesets can now be used to evaluate which transactions are independent and can be executed in parallel on the binary log applier on the asynchronous slaves. This was introduced with Group Replication, but now it can also be applied to asynchronous replication. It allows a greater degree of parallelism to reach the binary log applier on the slave and can be particularly beneficial when there is low concurrency on the master or when the parallelism potential decreases as the replication stream passes through intermediate masters in multi-level replication topologies.

This feature can have a significant impact on deployments that suffer from slave lag and provides a fast catch-up mechanism for replication because even single-threaded workloads can be executed parallel on the slaves after the slave has been delayed or has been restored from backup. As a bonus, it can even be beneficial to MySQL 5.7 slaves, as the binary logs generated are backward compatible. The details are availablehere.

2. WL#8599 – Reduce contention between IO and SQL threads

The coordination between the IO threads and the SQL threads is critical to the throughput of the binary log applier on the slaves. In very active replication slaves those threads contend for access to the relay log, which previously could lead to a significant decreased in throughput.

João Gramacho did a great work refactoring that code and now there is little contention there, achieving close to the same throughput on the applier independently of the IO thread being very busy or not. For more details check thisblog post.

3. WL#7374 – replication monitoring

Finally, there is now better monitoring of the replication pipeline using performance schema, a great addition for performance tuning that allows users to easily check what is happening on the slave applier. Please check out Maria Couceiro’sblog post for further information on how to use it.

4. BUG#82422 – improved GTID throughput on the master

It is also worth mentioning that MySQL 8.0.1 includes a fix to improve the throughput of the master when many clients issue small transactions with GTIDs, first introduced in MySQL 5.7.17. Please check the bug report for further details.


MySQL 8.0.1 replication provides higher throughput on the binary log applier on the slaves, making slave lag much less of an issue even on workloads with low concurrency deployed on multi-level topologies with modern storage systems. And it can increase the throughput of the master at high concurrency with small transactions. And it even brings better monitoring of what is happening on the slave.

If that triggers your curiosity, please try it out and provide us some feed-back, this is a great moment to influence how MySQL 8.0 will turn out to be.

MySQL High Availability

责编内容by:MySQL High Availability (源链)。感谢您的支持!


02_Linux系统下mysql的安装 @Author Jacky Wang 转载注明出处 一、在线安装【推荐】...
Select the first and last two items hi i have a table with this elements id name 1 luke 2 johnny 3 perry 4 jenny 5...
Playing with Memcached Plugin I am currently playing a lot with the new memcached interface to MySQL. Making M...
Orchestrator at GitHub GitHub uses MySQL to store its metadata: Issues, Pull Requests, comments, organ...
Where are the java.sql.Conne... I am using the Interface Connection from the package java.sql Actually I thoug...