MySQL 9.1 Release Notes
Group Replication is versioned according to the MySQL Server version that the Group Replication plugin was bundled with. For example, if a member is running MySQL 9.1.0 then that is the version of the Group Replication plugin. To check the version of MySQL Server on a group member issue:
SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| member_host | member_port | member_version |
+-------------+-------------+----------------+
| example.com | 3306 | 9.1.0 |
+-------------+-------------+----------------+For guidance on understanding the MySQL Server version and selecting a version, see Section 2.1.2, “Which MySQL Version and Distribution to Install”.
For optimal compatibility and performance, all members of a group should run the same version of MySQL Server and therefore of Group Replication. However, while you are in the process of upgrading an online group, in order to maximize availability, you might need to have members with different MySQL Server versions running at the same time. Depending on the changes made between the versions of MySQL, you could encounter incompatibilities in this situation. For example, if a feature has been deprecated between major versions, then combining the versions in a group might cause members that rely on the deprecated feature to fail. Conversely, writing to a member running a newer MySQL version while there are read/write members in the group running an older MySQL version might cause issues on members that lack functions introduced in the newer release.
To prevent such issues, Group Replication includes compatibility policies that enable you to combine members running different versions of MySQL in the same group safely. A member applies these policies to decide whether to join the group normally, or join in read-only mode, or not join the group, depending on which choice results in the safe operation of the joining member and of the existing members of the group. In an upgrade scenario, each server must leave the group, be upgraded, and rejoin the group with its new server version. At this point the member applies the policies for its new server version, which might have changed from the policies it applied when it originally joined the group.
As the administrator, you can instruct any server to attempt to
join any group by configuring the server appropriately and issuing
a START GROUP_REPLICATION
statement. A decision to join or not join the group, or to join
the group in read-only mode, is made and implemented by the
joining member itself after you attempt to add it to the group.
The joining member receives information on the MySQL Server
versions of the current group members, assesses its own
compatibility with those members, and applies the policies used in
its own MySQL Server version (not the
policies used by the existing members) to decide whether it is
compatible.
The compatibility policies that a joining member applies when attempting to join a group are as follows:
A member joins a group normally if it is running the same MySQL Server version as the lowest version that the existing group members are running.
A member joins a group but remains in read-only mode if it is running a higher MySQL Server version than the lowest version that the existing group members are running. This behavior only makes a difference when the group is running in multi-primary mode, because in a group that is running in single-primary mode, newly added members default to being read-only in any case.
Members take into account the entire major.minor.release version of the software when checking compatibility.
In a multi-primary mode group with members that use different
MySQL Server versions, Group Replication automatically manages
members' read/write and read-only status. If a member leaves
the group, the members running the version that is now the lowest
are automatically set to read/write mode. When you change a group
that was running in single-primary mode to run in multi-primary
mode using
group_replication_switch_to_multi_primary_mode(),
Group Replication automatically sets each member to the correct
mode. Members are automatically placed in read-only mode if they
are running a higher MySQL server version than the lowest version
present in the group, and members running the lowest version are
placed in read/write mode.