I'm looking for a production ready mysql with group replication, and wondering if there was a difference between v5.7 and v8.0 Group Replication implementation?

Keeping Group Replication and system stability in mind, would one version be preferred and/or more stable than the other?

  • I'm looking for stability over new features. Bit worried about 8.0 having new features/improvements which has risks of bug regressions.
    – Ken
    Nov 2 '19 at 3:43
  • 1
    Thanks for the advice, you have convinced me. I just finished setting up 5.7 but will reinstall with 8.0 now :)
    – Ken
    Nov 2 '19 at 5:14

Since you ask specifically about Group Replication and state that reliability is of great importance, the MySQL 8.0: New Features in Replication post talks specifically about improvements with this functionality and MySQL 8.0. I've quoted and referenced the specific portions of this that talks about what I feel are important factors to be considered in making a determination.

MySQL 8.0: New Features in Replication

Recently a new technology, MySQL Group Replication, was released in MySQL 5.7, and later it was also included in MySQL 8. It is continuously improved either through bug fixing or new features in both MySQL 5.7 and MySQL 8. But this is not the only new thing in MySQL 8. There is more.

Relevant replication areas that have been improved in MySQL 8:

  • Resiliency: crash-recoverable DDLs in replication.

Performance and Efficiency

Making replication efficient and fast is also something that is continuously worked on. In MySQL 8, there are a set of features that enhance the replication applier pipeline, so that it is able to ingest more load coming in, faster and in a more efficient way. Here are the highlights:

  • Transactions spend less time in the replication applier pipeline. There is an improved synchronization mechanism between receiver and applier threads, which translates into less contention between receiver and applier threads. This enhancement allows both receiver and applier threads to do more work in parallel instead of serializing themselves in a lock that protects the relay log.

  • More transactions are applied in parallel. Much improved parallel applier by relying on transaction WRITESETs (roughly the set of rows changed). This also allows the applier to install changes in parallel even for single threaded workloads coming in from replication. There is much to say about this feature, but you can learn more about the details here.

  • Predictable and sustained replication throughput fine tuning flow control. Flow control was also revised and improved. The user can now fine tune a group replication cluster so that the impact of imbalanced members is limited and the entire system converges to a sustained throughput.


Metaphorically speaking, MySQL has had a brain transplant. It has now a new data dictionary, which among other improvements also brings in crash-recoverable dictionary changes. Roughly, this makes DDLs atomic and recoverable. This functionality is also extended to include binary log recoverability for DDLs.

  • On recovery, recover my atomic DDLs too! When the server is restarting after a crash, the binary log and the InnoDB synchronize on to figure out which transactions to recover to bring both to a consistent state. Now atomic DDLs recovery also takes into account the contents of the binary log, so that metadata and the binary log is consistent.

  • On recovery, recover my atomic DDLs too… Oh, and my applier positions as well! If a crash happens while a replication applier is applying an atomic DDL, then recovery will make sure that the replication positions are consistent with the metadata changes.



Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.