For optimal compatibility and performance, all members of a group should run the same version of MySQL Server and therefore of Group Replication. However, in some situations, it may be required to that a group contains servers running different versions. For example, during a rolling upgrade. When different versions exist in the group, there is a potential for some members to be incompatible with others, because they support functions others do not or lack functions others have. Therefore, group replication implements compatibility policies to prevent running into incompatible version combinations scenarios.
In MySQL 8.0.17 the compatibility policies that Group Replication implements for member versions in groups considers the patch version of a member’s MySQL Server release.
Previously, only the major version used to be considered. Using the patch version means Group Replication can better maintain replication safety for a mixed version group during group reconfigurations and upgrade procedures.
Contents
- Primary member selection
- Primary member election algorithm
- Group with 8.0.17 or higher member version
- Group with at least one 8.0.16 or lower member version
- User Triggered Primary Switch-over
- Group with 8.0.17 or higher member version
- Group with at least one 8.0.16 or lower member version
- Write version compatibility
- Lowest version compatibility
- Donor version compatibility
- Upgrade
- Conclusion
Primary member selection
One of the parameter while selecting a new primary is a member version for replication safety. From 8.0.17 onwards, patch level is also considered while selecting new primary.
Therefore there are minor differences in what will be the next primary based on the group configuration.
Primary member election algorithm
During fail over of primary member new primary is selected based on following algorithm:
- Group with 8.0.17 or higher member version
-
- the lowest member version of the group including patch level
- higher member weight within the lowest members of the group as per step-1
- lexical order of server uuid within lowest members of the group with same member weight
- Group with at least one 8.0.16 or lower member version
-
- the lowest member version of the group considering major version
- higher member weight within the lowest members of the group as per step-1
- lexical order of server uuid within lowest members of the group with same member weight
Examples
E1: Group members after the previous primary left:
5.7.22,
8.0.20,
8.0.20
The server with 5.7.22 will be elected as the primary since its lowest version of the group.
All the members in the group have version 8.0.17 or higher.
Examples
E1: Group members after the previous primary left:
8.0.19,
8.0.20,
8.0.20
The server with 8.0.19 will be elected as the primary since its lowest version.
E2: Group members after the previous primary left:
8.0.19 weight: 90,
8.0.19 weight 50,
8.0.20 weight 90,
8.0.20 weight 95
The server with 8.0.19 weight: 90 will be elected as the primary since its lowest version of the group with higher member weight.
E3: Group members after the previous primary left:
8.0.19 weight 90 uuid: 5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c,
8.0.19 weight 90 uuid: 5a67adc9-6ad1-11e7-9b1f-f48c5048ab0c,
8.0.19 weight 50 uuid: 5a6e5078-6ad1-11e7-9bce-f48c5048ab0c
The server with 8.0.19 weight: 90 uuid: 5a5d0f6e-6ad1-11e7-9aee-f48c5048ab0c will be elected as the primary member since its lowest version of the group with higher member weight and lowest server uuid.
There is atleast 1 member in the group with version lower then 8.0.17.
User Triggered Primary Switch-over
If primary member is being changed using UDF, group_replication_set_as_primary(server_uuid) or group_replication_switch_to_single_primary_mode([server_uuid]), then some precautions are also taken to make sure all members are compatible and can carry out desired change. The algorithm is as follow:
- Group with 8.0.17 or higher member version
-
- If server_uuid is provided, that server will be made primary member, if its version is lowest (considering the patch level) in the group, else an error will be thrown.
- If server_uuid is not provided then the election will happen considering the group members version till patch level.
- Group with at least one 8.0.16 or lower member version
-
- If any of the members in the group have version 5.7 or version less than 8.0.13, the function will not make any primary member changes.
- If server_uuid is provided with major version 8, that server will be made primary member else error will be thrown.
- If server_uuid is not provided then the election will happen considering the only major release of the group members version.
NOTE: For UDF group_replication_set_as_primary server_uuid is mandatory. UDF will fail if server_uuid is not provided.
Examples
E1: Group members during multi-primary-mode to single-primary-mode switch:
8.0.14 weight 90,
8.0.20 weight 50,
8.0.20 weight 90,
8.0.20 weight 95
The server with 8.0.20 weight: 95 will be elected as the primary since its lowest major version (patch version ignored due to 8.0.14 presence in group) of the group.
All the members in the group have version 8.0.17 or higher.
Examples
E1: Group members during multi-primary-mode to single-primary-mode switch:
8.0.19 weight 50,
8.0.20 weight 90,
8.0.20 weight 95
The server with 8.0.19 weight: 50 will be elected as the primary since its lowest patch version of the group.
There is atleast 1 member in the group with version lower then 8.0.17.
Write version compatibility
From 8.0.17, if new member version is higher than the lowest member version (considering the patch level) of the group then a new member will be in read-only mode.
If the group enters multi-primary mode by executing UDF group_replication_switch_to_multi_primary_mode, lowest member versions of the group will be writable while other members will be in read-only.
Members with version 8.0.16 or less, join a group in read-only mode if any member in the group has 5.7 version.
Members with version 5.7 are always writable since 5.7 considers only the major version.
In MySQL 5.7 and 8.0 till patch level 16, a user has to manually re-configure read-only mode when low version member leaves the group.
NOTE: This only applies to multi-primary mode.
Examples
E1 Group members in multi-primary-mode:
8.0.19,
8.0.20
Server with version 8.0.19 will be writable while 8.0.20 will be read_only.
E2 Group members during single-primary-mode to multi-primary-mode switch:
8.0.19(Primary),
8.0.19(Secondary),
8.0.20(Secondary),
8.0.21(Secondary),
Servers with version 8.0.19 will be writable while 8.0.20 and 8.0.21 will be the read_only post-multi-primary switch.
E3 Group members in multi-primary-mode:
5.7.21,
8.0.15
Server with version 5.7.21 will be writable while 8.0.15 will be read_only.
E4 Group members during single-primary-mode to multi-primary-mode switch:
8.0.14(Secondary),
8.0.15(Secondary),
8.0.20(Secondary),
8.0.21(Primary),
Server with version 8.0.14 and 8.0.15 will be writable (old releases) while 8.0.20 and 8.0.21 will be read_only.
Server 8.0.21 will enable read_only mode.
Lowest version compatibility
From 8.0.17, if new member version is lower than the lowest member version (considering the patch level) of the group then a new member will not join the group.
Member with version 5.7 cannot join a group containing only 8.0+ members.
Member with version 8.0.16 or less can join any group since it considers only major version.
Examples
E1: Group members:
8.0.19,
8.0.20,
8.0.20
Servers with version 8.0.17 or 8.0.18 will not be able to join the group.
E2: Group members:
8.0.15,
8.0.16
Servers with version 5.7.27 will not be able to join the group.
Donor version compatibility
From 8.0.17, while forming the list of possible donors group, ONLINE members with an equal or lower version than the new member are considered as a valid donor. However, if allow_local_lower_version_join is set, all ONLINE members of the group can act as a valid donor since there will be no equal or lower version member.
Group replication versions at 5.7 level or MySQL 8.0 till 8.0.16 considers all ONLINE members as active donor for recovery.
Examples
E1: Group members:
5.7.22,
8.0.20,
8.0.21
A new member 8.0.20 can use 5.7.22 or 8.0.20 as a donor.
E2: Group members:
5.7.22,
8.0.20,
8.0.21
A new member 5.7.22 can use 5.7.22, 8.0.20 or 8.0.20 as a donor.
Upgrade
For single-primary in-place upgrade, customer can update each secondary member first followed by the primary member at the end.
Later customer can make desired member primary using UDF group_replication_set_as_primary.
Or the customer can assign higher member weight to the desired member and upgrade group, upgrading the desired primary first.
For multi-primary in-place upgrade, members may be upgraded in any order. During the process of complete group upgrade, upgraded members will be in read-only mode due to higher version. Once all members of the group are upgraded to same patch level all members will become writable.
Some notes on undesired upgrade:
-
Member will not join the group if its version is lower than the lowest member version of the group (considering patch level)
- If post-upgrade, versions are not going to be same patch level, new lowest member version should be first started.
-
If all the members in the group are at versions greater than 8.0.16 then the member is allowed to become primary, only if the member is the lowest version (including patch level) in the group.
- If the primary has to stay the same post-upgrade, primary only upgrade (including patch level) is not possible post this WL. Secondary member(s) of the group should be upgraded to version higher or equal to that of Primary member version.
Examples
E1(Single-primary upgrade)
M1: 8.0.20 (old primary)
M2: 8.0.20 (new primary)
M3: 8.0.20
DBA wants to upgrade all group members to 8.0.21
Set higher member weight on M2 and upgrade M2.
Upgrade M3 and M1 now.
Post M1 and M3 upgrade M2 will become Primary.
E2(Single-primary upgrade)
M1: 8.0.20 (primary)
M2: 8.0.20
M3: 8.0.20
DBA wants to upgrade all group members to 8.0.21
Upgrade M2 and M3 to version 8.0.21 or higher.
Post M2 and M3 upgrade, M1 can be upgraded to 8.0.21. Using UDF group_replication_set_as_primary M1 can become primary.
E3:(Multi-primary upgrade)
M1: 8.0.20,
M2: 8.0.20
DBA wants to upgrade all group members to 8.0.21
Upgrade M1.
Post upgrade of M1, M1 will be read-only till M2 is upgraded to 8.0.21.
Once M2 is upgraded to 8.0.21, M1 will become writable.
Conclusion
MySQL 8.0.17 is publicly available and with it comes improvements to Group Replication. Now Group replication adds more safety and ensures transactions generated by members are compatible with each member of the group.
Interested in exploring all the latest in MySQL high availability? Check out this page to explore all the latest enhancements.