MySQL Group Replication for MySQL 5.7.15

Hi all, it is time again to do another preview release of MySQL Group Replication, the plugin that brings multi-master update everywhere support to MySQL, like we described in the Hello World post.

We are very proud to present the eighth preview release of MySQL Group Replication plugin, based on MySQL Server 5.7.15. It introduces a couple of exciting features and several bug fixes. Please enjoy the highlights!

Changes Introduced

Parallel Applier Support
Group Replication now also takes full advantage of the parallel binary log applier infrastructure. This reduces applier lag and improves replication performance considerably. Stay tuned for a follow up blog post on this matter that includes detailed benchmarks.

The Group Replication parallel applier is configured in the same way as in asynchronous replication:

Though on Group Replication slave_parallel_type must be "logical_clock" and slave_preserve_commit_order must be enabled.

Single Primary Mode
It is a configuration mode for Group Replication that makes a single member act as a writeable master (PRIMARY) and the rest of the members act as hot-standbys (SECONDARY). The group itself coordinates and configures itself automatically to determine which member will act as the PRIMARY, through a leader election mechanism.

The main motivation behind this new configuration mode is to provide the “single master” behavior–from a user and application point of view–to Group Replication users, as this is closer to what many users are used to with asynchronous replication. They can now get that same data perspective, while still taking advantage of the automatic membership and failover features innate to Group Replication.

It can be controlled with: group_replication_single_primary_mode=TRUE|FALSE
Which enables/disables the single primary mode–enabled now being the default.

And by: group_replication_enforce_update_everywhere_checks=FALSE|TRUE
Which enables/disables strict consistency checks for multi-master update everywhere, that too now being disabled by default.

The current PRIMARY member’s UUID can be known by executing the following SQL statement:

When single primary mode is disabled, the group_replication_primary_member variable value is empty.

Bug Fixes

There are a lot of bugs that have been fixed in this eighth preview release of MySQL Group Replication, including group communication engine stabilization fixes, all of which has us moving quickly towards a more stable, reliable, and full-fledged plugin.


Go to and try the new preview release of MySQL Group Replication following the instructions at Quick Start Guide and send us your feedback.

As with all labs releases, we are not recommending that this software be used in production as there are likely still a number of bugs which need to be fixed. This is not a GA release, even though it is a much more stable version of the plugin. If you do encounter any issues, please file a bug under the ‘MySQL Server: Group Replication’ category so that we may investigate further.

THANK YOU for using MySQL, and for trying out Group Replication!

About Nuno Carvalho

Nuno Carvalho is a Principal Software Engineer and MySQL Replication Service Team lead at Oracle, the team in charge of MySQL Group Replication plugin. His research interests include replication technologies, dependable systems and high availability. Before joining the MySQL team, he was a post-graduate student and a researcher at the University of Minho, Portugal, where he designed and implemented techniques to improve distributed systems scalability.

3 thoughts on “MySQL Group Replication for MySQL 5.7.15

  1. Hi, I am asking about “Single Primary Mode”.
    I have read the source code and find that the function “handle_leader_election_if_needed” just choose the first member after sorting all members in a group. And there is no Paxos related algorithm applied, which is much different from leader election mechanism as usual. So how can it work?

    1. Hi Jie,

      Thank you for your question, the Group Replication Single-primary mode is a configuration mode that makes a single member act as a writeable master (PRIMARY) and the rest of the members act as hot-standbys (SECONDARY).
      This primary/secondary profile does exist at MySQL layer only, at Paxos layer everything remains the same, that is, all members are able to propose messages. That is the reason why you do not see a Paxos leader election, which is a completely different thing.

      You can see more details about our Paxos implementation at

      Best regards,
      Nuno Carvalho

Leave a Reply

Your email address will not be published. Required fields are marked *

Please enter. * Time limit is exhausted. Please reload CAPTCHA.