Group Replication Online Upgrade 18.8.3.2 Upgrading a Group Replication Member Important Note •When MySQL 5.7.22 or MySQL 8.0.11 tries to join a group running MySQL 5.7.21 or lower it fails to join the group because MySQL 5.7.21 does not send its value of  lower_case_table_names . •Connect a client to the group member and issue  STOP GROUP_REPLICATION . Before proceeding, ensure that the member’s status is  OFFLINE  by monitoring the  replication_group_members  table. •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  group_replication_start_on_boot=0 . •Stop the member, for example using  mysqladmin shutdown  or the  SHUTDOWN  statement. Any other members in the group continue running. •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_boot  is 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_boot  must 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. 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. If an upgraded member has   group_replication_start_on_boot=1  then 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. This section explains the steps required for upgrading a member of a group. This procedure is part of the methods described at Section 18.8.3.3, “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: 3790