Replication Features in MySQL 8.0.2

MySQL 8 is shaping up quite nicely. And we are having a blast in the MySQL replication team while this is happening. We are continuously improving all-things-replication by introducing new and interesting features. In addition, we have been listening to our community and addressing their feedback. As such, we would like to celebrate with you all the latest development milestone release, MySQL 8.0.2, by summarizing the noteworthy changes that are in it. Follow up blog posts shall provide insights on these new enhancements.

We have extended Group Replication with the following features:

  • Disallow changes to members that have left the group. Whenever a member leaves the group voluntarily, it will automatically set super_read_only. This prevents accidental changes from the DBA, user, or router/proxy/load balancers. In addition to disallowing changes on members that have left the group by default, it is also possible to protect the writes from the beginning. I.e., it is possible to set super_read_only and start the group replication plugin while the server starts. Once Group Replication starts successfully, it will adjust super_read_only’s value properly. On multi-primary mode, the super_read_only will be unset on all joining members; On single-primary, only the primary will have super_read_only unset.  In the unlikely event that Group Replication fails to start, the super_read_only is preserved, thence no writes are allowed.  This last change is actually in both, MySQL 5.7.19 and MySQL 8.0.2. All of these were highly influenced by feedback we got from our community (BUG#84728, BUG#84795, BUG#84733) – Thank you Kenny Gryp!
  • More information on Performance Schema tables. More observability enhancements were added to existing performance schema tables. “replication_group_members” and “replication_group_member_stats” tables have been extended and now display information such as members roles, members versions and counters for the different types of transactions (local/remote).
  • Influence primary election by assigning promotion weights. The user is able to influence the primary election by determining member weights. When the existing primary goes away, the member with the highest weight is the one to be elected on fail-over.
  • Fine tuning options for the flow control mechanism. Users can now do more fine tuning of the flow control component. They can define the minimum quota per member, minimum commit quota for the entire group, the flow control window, and more!

MySQL 8.0.1 already showed a long and compelling list of features added to the core framework of MySQL Replication. MySQL 8.0.2 brings more enhancements to this area as well:

  • Enhanced management of the receiver (IO) thread even when disk is full. This feature improves the internal coordination between receiver and other threads, removing some contention. To the end user, this means that in the event that the disk becomes full and the receiver thread blocks, it no longer blocks monitoring operations, such as SHOW SLAVE STATUS. A new thread state is also introduced stating that the receiver thread is waiting for disk space. Moreover, when the disk is full and you cannot free disk space up to allow the receiver thread to continue its activity, you can forcefully stop it, generally without side effects. If there is an event that is partially written this is cleared and relay log is left in a consistent state. Some extra care needs to be taken when receiver thread is rotating the relay log and is waiting for disk space to become available.
  • More metadata into the binary log. Added the length of the transaction to the global transaction log event. This enables potential future optimizations to be implemented as well as better observability support into the binary log.

If you are into MySQL replication internals, we are happy to let you know that we have done some clean ups and added one interesting service to our components infrastructure:

  • Group membership events are propagated to other components internally. By taking advantage of the new services infrastructure, the group replication plugin can now notify other components in the server about membership related events. For instance, notify that membership has changed and that quorum was lost. Other components can react to this information. Users can write their own components that register and listen to these events.
  • Removed redundant information on nodes from internal structures in XCom. This work removed a bit of redundant information in XCom’s structures, making it simpler and less error prone to track which servers have left and rejoined, while there is still stale information in the system about previous views.
  • Several enhancements to XCom core and new coding style. XCom has had several bug fixes and its code was reformatted to meet the google coding guidelines. If you are a developer and enjoy looking at our Paxos implementation, this will make it easier for you to read and understand the code.
  • Removed cross version conversion code for very old binary log formats. This is a clean up that removes code converting binary logs generated  by very old versions of MySQL to a newer format as understood by newer versions of MySQL (versions 5.0 and higher).

It is also interesting to note that we have changed the following replication defaults in MySQL 8.0.2:

  • Replication metadata is stored in (InnoDB) system tables by default. This makes replication more robust by default when it comes to crashing and recovering automatically the replication positions. Also, newer features require the metadata information to be stored in tables (e.g., group replication, mutli-source replication). It aligns with the overall direction of MySQL 8 and the new data dictionary in it.
  • hash scans for row-based applier are enabled default. Perhaps not a popular knob, but one that helps when slaves do not have tables with primary keys. This change will minimize the performance penalty in that case, when using row-based replication, since it reduces the number of table scans required to update all rows.
  • Write set extraction is enabled by default. With write set extraction, it is one less configuration step for the user to start group replication or use WRITESET based dependency tracking on the master.
  • Binary log expiration is enabled by default. The binary logs are expired after 30 days by default (expire-logs-days=30).

As you can see, we have been busy. 🙂 In fact, MySQL 8.0.2 is showing a great feature set across the board. On the replication side, we are very happy to see so many interesting features getting released.

Stick around as there will be blog posts detailing further the features mentioned above. Actually, go and try them yourself, as you can download a MySQL 8.0.2 packages here. Note that MySQL 8.0.2 is a development milestone release (DMR), thence not declared generally available yet. Use it at your own risk. Don’t forget, feedback is always welcome and highly appreciated. You can send it to us through bug reports, feature reports, the replication mailing list or by just leaving a comment on this (or subsequent) blog posts. MySQL 8 looks rather nice! Exciting! 😉

 13,480 total views,  10 views today

About Luis Soares

Luis Soares is the MySQL Replication Director at Oracle. His research interests include replication technologies, dependable systems and high availability. Before joining the MySQL team, he was both a post-graduate student and a researcher at the University of Minho, Portugal, where he designed and implemented group-based replication protocols. Before that, he worked for a Portuguese multi-national company as a system analyst.

7 thoughts on “Replication Features in MySQL 8.0.2

  1. Alot of people are still waiting to see some improvements in real HA 🙂 . Currently I don’t see a way of making sure that reading data from a newly elected leader/master will be consistent with the failed master. This is mostly because applying changes from relay log is done in an async manner.

    1. Hi George,

      Yes, currently Group Replication favors availability over consistency when a failure happens. That is, it doesn’t pause/block new traffic until the newly elected primary’s applier queue empties out. Note: it does enable conflict detection though during this time to prevent any conflicts and ensure eventual consistency. In practice, the applier queue will typically flush by the time the failover completes, but that’s not guaranteed–especially if you have some long running commands in the queue such as DDL or a huge batch write. I would like to add a configuration option in MySQL 8 to force a newly elected primary to pause/block traffic until its existing applier queue is empty, thus guaranteeing this basic property/assumption:
      Any read from the primary, at any point in time, will always return the latest data. It should then in effect offer something vaguely like “serializability” consistency–in reality you’d have the same consistency level you set for the local InnoDB engine (e.g. repeatable-read or read-committed).

      Of course you need to keep in mind that some updates can take minutes or even hours to complete. So you’ll need to be careful about DDL and large batch operations in the system as if a failure happens shortly after they complete, your system could be unavailable (not serving new requests) for a long time while those writes are applied on the new primary.

      Best Regards

      1. Thank you for your reply Matt

        Yes, having such a block reads feature would be nice mostly because alot of people expect a program to make business decisions based on persisted data. And reading stale data it’s a big no when it comes to business decisions 🙂 .
        Your target users range will get alot bigger (in my opinion) when this features will be implemented. Also would be nice to get back a clear message when a query would fail because of this “stale data block/lock”. This way we can wait a bit and retry the queries (like you said in practice, the relay log queue will become empty pretty fast, so no issue in waiting and retrying some queries when a “data consistency lock is detected”).

        Also another question I would have. Is there a way to detect if the applier queue is empty or not from client side? Or some way to properly detect if there is any stale data on a possible newly elected primary node?

        1. Hi George,

          Yes, I agree that this option is highly desirable. 🙂

          After a failover where the newly elected primary has a non-empty applier queue to drain–I would prefer to have the new client requests block until a timeout is hit, so that in most cases no client retry is necessary and when it is there is a clear error code to indicate the cause and you can choose the action (in most cases a simple retry).

          In 5.7 you can only estimate the applier queue length. You can see how I did that here (see gr_applier_queue_length() function).

          In 8.0 (now in Release Candidate) it’s very simple, you can look at the performance_schema.replication_group_member_stats.count_transactions_remote_in_applier_queue value on the newly elected primary.

          Best Regards,


          1. Thank you for the response. I know , some of us who use these tools are picky sometimes. You are doing a great job with these new features!

Leave a Reply