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 available here.
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 this blog 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’s blog 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.
Summary
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.