This section explains the steps required for upgrading a member of a group. This procedure is part of the methods described at Section 184.108.40.206, “Group Replication Online Upgrade Methods”. The process of upgrading a member of a group is common to all methods and is explained first. The way which you join upgraded members can depend on which method you are following, and other factors such as whether the group is operating in single-primary or multi-primary mode. How you upgrade the server instance, using either the in-place or provision approach, does not impact on the methods described here.
The process of upgrading a member consists of removing it from the group, following your chosen method of upgrading the member, and then rejoining the upgraded member to a group. The recommended order of upgrading members in a single-primary group is to upgrade all secondaries, and then upgrade the primary last. If the primary is upgraded before a secondary, a new primary using the older MySQL version is chosen, but there is no need for this step.
To upgrade a member of a group:
Disable Group Replication from starting up automatically so that you can safely connect to the member after upgrading and configure it without it rejoining the group by setting
If an upgraded member has
group_replication_start_on_boot=1then it could rejoin the group before you can perform the MySQL upgrade procedure and could result in issues. For example, if the upgrade fails and the server restarts again, then a possibly broken server could try to join the group.
Upgrade the member, using the in-place or provisioning approach. See Section 2.11, “Upgrading MySQL” for details. When restarting the upgraded member, because
group_replication_start_on_bootis set to 0, Group Replication does not start on the instance, and therefore it does not rejoin the group.
Once the MySQL upgrade procedure has been performed on the member,
group_replication_start_on_bootmust be set to 1 to ensure Group Replication starts correctly after restart. Restart the member.
Connect to the upgraded member and issue
START GROUP_REPLICATION. This rejoins the member to the group. The Group Replication metadata is in place on the upgraded server, therefore there is usually no need to reconfigure Group Replication. The server has to catch up with any transactions processed by the group while the server was offline. Once it has caught up with the group, it becomes an online member of the group.Note
the longer it takes to upgrade a server, the more time that member is offline and therefore the more time it takes for the server to catch up when added back to the group.
When an upgraded member joins a group which has any member
running an earlier version, the upgraded member joins with
of whether it was a primary or secondary. This ensures that no
writes are made to upgraded members until all members are
running the newer version. In a multi-primary group, once you
are sure the upgrade has been successful and the group is ready
to process transactions, it is necessary to manually configure
members which should become writeable primaries. Connect to each
member and issue:
SET GLOBAL read_only=off;