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.MINOR.PATCH
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.
|
1
2
3
4
5
6
7
8
|
SELECT PLUGIN_VERSION FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME="group_replication"; +----------------+ | PLUGIN_VERSION | +----------------+ | 0.4 | +----------------+ |
This version depicts the plugin’s major and minor versions.
In Group replication, to know your plugin full version you query the description.
|
1
2
3
4
5
6
7
8
|
SELECT PLUGIN_DESCRIPTION FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME="group_replication"; +---------------------------+ | PLUGIN_DESCRIPTION | +---------------------------+ | Group Replication (0.4.0) | +---------------------------+ |
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:
- 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.
Member with lower patch version joins – success 
Member with lower minor version joins – failure 
Member with higher minor version joins – success - 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:
|
1 |
SET GLOBAL group_replication_allow_local_lower_version_join= ON; |
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:
- 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.
- 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.
Conclusion
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.