MySQL Blog Archive
For the latest blogs go to
MySQL Group Replication: Plugin Version Access Control.

Here is version 0.4.0 of the MySQL Group Replication plugin, our solution that gives you virtual synchronous updates on any member of a MySQL server group. With this new version you can expect a bunch of bug fixes and new features.

One of the new feature that marks this release is the access control of different plugin versions in a server group. In an evolving product like Group Replication, it is important to assure the correct functioning of the group by automatically check that all servers have a compatible plugin versions.

Plugin versions – the basics

As you may have noticed, the Group Replication plugin has an independent life cycle from the MySQL server, characterized by frequent releases. Each one of theses releases is marked with an individual version that follows the  Semantic Versioning format :


MAJOR= Plugin’s major version
MINOR= Plugin’s minor version
PATCH= Plugin’s patch version

Major versions are associated to important releases that introduce adjustments to the API or some major behavior change. On the other hand, Minor versions are associated to incremental improvements of a said major version. Finally Patch versions are associated to minor corrections or bug fixes to the code.

Look up your version

As you may know, not only Group Replication, but every other plugin in MySQL has also an associated version that can be consulted under the performance schema plugin table.

This version depicts the plugin’s major and minor versions.
In Group replication, to know your plugin full version you query the description.

Here you can see not only the major and minor versions but also the patch version.

Plugin version rules

The basic rules

Why are versions important in Group replication?

When joining, versions are crucial when determining if a member is compatible with a group. A higher major version can indicate that the member has some messaging incompatibilities with the group.

The basic rules for version handling in Group Replication are then:

  1. When a lower version member tries to join the group, its request will be denied and the member will become offline. This is  justified by concerns of possible new features that are not support by this member version. These rules does not apply to patch version variations however, as they represent minor changes or bug fixes.
    Patch versions do not affect the version control mechanism
    Member with lower patch version joins – success
    Members with lower versions cannot enter the group without the force option.
    Member with lower minor version joins – failure

    A higher version member is always accepted into the group if no exception exists.
    Member with higher minor version joins – success

  2. While the above rule guarantees safeness in most cases, there can be situations
    where, for example, a needed fix on version 1.7.0 makes it incompatible with its lower versions 1.6.N and 1.5.N. To tackle this, group replication also supports built in incompatibilities rules for these specific cases. Higher versioned plugins can then join the group, unless there is a incompatibility rule registered in it.

    These rules are coded into the plugin, they are not visible and cannot be changed or overridden by the end user. Nevertheless, these exception shall be properly documented.

Override lower version incompatibilities

From the above described rules, there is one kind that can be overridden: the lower version incompatibility rule.

If the there are no documented interoperability issues between two versions, the user can force the entry of a lower version member into the group by setting:

This will allow the member to join a group with higher versions.

 A few words on the joining process

Now diving into the details, some basics about the joining process are presented here as they are important to understand how the member enters and is rejected by the group and how this is seen by the end user.

First of all, the decision process is local, meaning that it is the joining member that knows if it is incompatible with the group or not. It makes sense as only a member with a higher version, when joining, knows that it is incompatible with the lower version members.

Also, in what refers to the communication layer, the member always join the group and all members will receive a notification of this fact. This is also when all nodes, among other info, broadcast their versions so the new member can make a decision. So, it is only when the plugin process receives this notification that the compatibility with the group is checked. If the member is declared incompatible only then it will ask to leave.

This has 2 consequences:

  1. The START GROUP_REPLICATION command won’t fail as it only checks if  the member entered the group. The user must check that the member  in fact is recovering or became online after starting in a similar way to what is done when starting a MySQL slave.
  2. All the other members of the group will assume the node joined and will now start recovery. Only moments later they will be notified of a new group change where the member now left. This means that, for brief moments, the user can see the joiner status as being on recovery while checking the performance schema replication_group_members table on the other group members.



Go to labs releases and try the new preview release of MySQL Group Replication Plugin following the instructions at Getting started with MySQL Group Replication and send us your feedback.

Note that this is not the GA yet, so don’t use it in production and expect bugs here and there. If you do experience bugs, we are happy to fix them. All you have to do is to file a bug in the bugs DB in that case.