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 5.7.26 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 | 8.2.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 these issues, Group Replication includes compatibility policies that enable you to safely combine members running different versions of MySQL in the same group. 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
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
The compatibility policies that a joining member applies when attempting to join a group are as follows:
A member does not join a group if it is running a lower MySQL Server version than the lowest version that the existing group members are running.
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. (You should be aware that members running MySQL 8.0.16 or earlier take into account the major.minor version only.)
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 the
function, Group Replication automatically sets members 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.