MySQL Group Replication Version Compatibility Policies and Upgrade Guidelines

Background – For optimal compatibility and performance, all members of a MySQL Group Replication cluster should run the same server version, but mixed‑version groups may be required during rolling upgrades. Different versions can cause incompatibilities, so Group Replication implements compatibility policies to prevent unsafe version combinations.

Version‑aware Compatibility (MySQL 8.0.17+) – From MySQL 8.0.17 onward, the compatibility policy considers the full patch version of each member, not just the major version. This allows finer‑grained control of mixed‑version groups during reconfiguration and upgrades.

Primary‑Member Election Options

A. Primary‑Member Election Algorithm

When a primary fails, a new primary is chosen based on:

The lowest member version (including patch level) in the group.

If versions are equal, the member with the higher weight is preferred.

If weights are equal, the lexicographically smallest server UUID wins.

Examples illustrate how a server with version 8.0.19 (the lowest patch) or with a higher weight becomes the new primary.

B. User‑Triggered Primary Switch

If the primary is changed via the UDF group_replication_set_as_primary(server_uuid) or group_replication_switch_to_single_primary_mode([server_uuid]) , additional checks ensure all members are compatible before the change.

For groups where all members are 8.0.17 or higher, the algorithm is:

If a server_uuid is supplied, that server becomes primary only if its version is the lowest (patch‑aware); otherwise an error is raised.

If no server_uuid is supplied, the election proceeds using the version‑aware algorithm described above.

For groups containing at least one member older than 8.0.17, the algorithm first considers the lowest major version, then applies weight and UUID tie‑breakers.

Write‑Version Compatibility

From 8.0.17, a new member whose version is higher than the group’s lowest version (patch‑aware) joins the group in read‑only mode. In multi‑primary mode, only the members with the lowest version are writable; all others are read‑only. Versions 5.7 are always writable because they are evaluated only by major version.

Minimum‑Version Compatibility

A member whose version is lower than the group’s lowest version (patch‑aware) is rejected and cannot join the group. For example, a server running 8.0.17 or 8.0.18 cannot join a group whose members are 8.0.19, 8.0.20, 8.0.20.

Donor‑Version Compatibility

When forming a donor list, any ONLINE member with a version equal to or lower than the new member is considered a valid donor. If allow_local_lower_version_join is enabled, all ONLINE members can act as donors regardless of version.

Upgrade Guidelines

For single‑primary upgrades, update all secondary members first, then the primary. The UDF group_replication_set_as_primary can be used to promote the desired member after upgrade. For multi‑primary upgrades, members can be upgraded in any order; upgraded members become read‑only until the entire group reaches the same patch level, after which all become writable.

Important notes:

If a member’s version is lower than the group’s minimum, it will not join the group (patch‑aware).

If all members are newer than 8.0.16, only the member that is the lowest version (including patch) may become primary.

Conclusion

MySQL 8.0.17 introduces improved handling of mixed‑version groups in Group Replication, enhancing safety by ensuring that transactions generated by any member are compatible with all other members in the group.