https://dev.mysql.com/doc/refman/8.0/en/group-replication-upgrade.html
这个章节主要描述升级MGR的计划
基本的升级MGR成员的方法基本跟单独的实例升级一样（可参考 Section 2.11.1, “Upgrading MySQL”）
选择in-place，还是logical方式升级取决于数据量大小
通常in-place升级会非常的快速，因此也是官方最推荐的
由于MGR是分布式的环境，所以在升级的时候有一些考虑，比如：成员升级的顺序问题等
如果你的MGR环境可以允许offline，那么就参考下列的Group Replication Offline Upgrade 方法
如果你的MGR环境需要在online进行，参考Group Replication Online Upgrade方法（极小的downtime）
18.6.1 Group Replication Offline Upgrade
对一个MGR进行offline升级的时候，你需要将成员从group中分别移除掉，然后升级成员，然后重启这个group
在 multi-primary环境下，你可以按照任何顺序shutdown组成员
在 single-primary环境下，先shutdown secondary成员节点，最后shutdown primary节点
如何移除成员节点，你可以参考 Section 18.6.2.3, “Upgrading a Group Replication Member”
一点group变成offline，你可以就想升级单独的实例一样升级他们，参考 Section 2.11.1, “Upgrading MySQL”
所有成员升级完毕后，在重启成员
18.6.2 Group Replication Online Upgrade
当你需要在线升级MGR，且不影响你的application，那么你就需要考虑下自己的方法了
这一节主要描述online升级的一些考虑，方法，和步骤
18.6.2.1 Online Upgrade Considerations
当你需要online升级的时候，需要考虑如下几个点：
- 不管哪种升级group的方法，对组成员停写是至关重要的一步，直到它重新加入group
- 当一个组成员stop的时候，super_read_only 会自动设置成on，但是这个改变不会被写入配置文件，并不持久
- 当5.7.22或者8.0.11想要加入5.7.21或更低版本的group的时候会失败，因为5.7.21不会发送lower_case_table_names变量的值
18.6.2.2 Combining Group Replication Versions
不同版本的MySQL组合的GROUP可能会存在着不兼容性，这一章主要描述不同组合的最佳实践
如何查看版本
SELECT MEMBER_HOST,MEMBER_PORT,MEMBER_VERSION FROM performance_schema.replication_group_members;
+-------------+-------------+----------------+
| member_host | member_port | member_version |
+-------------+-------------+----------------+
| example.com | 3306 | 8.0.13 |
+-------------+-------------+----------------+
不同大版本group中的组合成员的规则如下：
- 如果你跑着一个8.0版本的GR，你需要添加一个成员为5.7的，这样就不行
- 如果你跑着一个5.7版本的GR，你需要添加一个8.0的成员是可以的，它必须保持read-only模式
不同小版本group中的组合成员的规则如下：
- 如果是小版本的之间的差异，是可以的随时加入进来的,且可读可写。如果是single-primary group，添加的成员默认是read-only模式
18.6.2.3 Upgrading a Group Replication Member
这一小节主要描述升级组成员版本的基本步骤
这里面的步骤是Section 18.6.2.4, “Group Replication Online Upgrade Methods”. 提到步骤的一部分
升级组成员版本的步骤包括：将成员移除组，接下来选择你要升级的方法，然后重新加入升级过成员的group
single-primary模式下的推荐升级方法是： 先升级所有的secondaries，然后再primary节点
升级一个组成员的方法：
- 连接一个成员，然后敲 STOP GROUP_REPLICATION. 在此之前，要确认下该成员状态是offline 通过 replication_group_members 表
- 设置group_replication_start_on_boot=0 防止成员已启动就自动加入，会有安全隐患（在你还没upgrade mysql之前就自动加入了 等等情况）
- 使用 mysqladmin shutdown关闭该成员，其他成员继续保持running
- 使用in-place方式升级该成员，由于你没有设置group_replication_start_on_boot=1，所以重新启动升级过的成员时，它不会自动加入MGR
- 一旦你使用mysql_upgrade升级成功后，再将 group_replication_start_on_boot 设置为1，这样可以确保之后重启服务器的时候可以自动加入进来
- 链接到升级成功过后的该成员，敲 START GROUP_REPLICATION.重新加入group。该server的元数据会自动重新配置，且开始追数据，一旦数据追完，它将变成online状态
当升级成功的成员加入到group中的时候，只要group中还有早期的的版本成员在，那么该成员都会自动被设置成 super_read_only=on,不管它是primary还是secondary
这样可以保证升级后的成员不会有写，直到所有的版本全部一致
但是如果是multi-primary模式的group，一旦确认升级成功，这个group就可以处理事务，所以该模式下人工配置哪个可以写，哪个不可以写是非常重要的步骤
SET GLOBAL read_only=off;18.6.2.4 Group Replication Online Upgrade Methods
- Rolling In-Group Upgrade
对于single-primary的group，一旦所有secondary节点都升级了，然后primary节点从group中移除出去升级的时候，一个新的primary节点会自动被选择出来
对于multi-primary的group，直到所有成员都被升级了，你才需要手动的给所有成员设置 super_read_only=OFF
对于multi-primary的group，在上述过程中，所有primaries被降级，会降低可用性。但是在single-primary模式中，就不会有影响
- Rolling Migration Upgrade
这个方法就是：你从组成员中移除成员，然后升级，然后用他们创建第二个group
对于multi-primary的group，在上述过程中，所有primaries被降级，会降低可用性。但是在single-primary模式中，就不会有影响
升级过程中，由于新版本的group为了追上老版本group的数据，因此在新版本的group中需要配置成老版本group中的slave角色
对于single-primary的group，该slave的角色，也必须是新版本group的primary角色
对于multi-primary的group，该slave的橘色，可以是任何一个primary角色
方法基本如下：
- 在origin group中一个个的移除成员，参考 Section 18.6.2.3, “Upgrading a Group Replication Member”
- 升级成员的版本 ， 参考 Section 2.11.1, “Upgrading MySQL”.
- 使用升级过的成员，创建一个新的group。你需要配置一个新的group name，因为老的name还在运行。
- 创建一个异步复制通道在新老group中。老的group的priamry作为master，新的group成员作为GTID-based slave
在你切换应用之前，你必须确保你的新的group有比较合适的成员数量
敲SELECT * FROM performance_schema.replication_group_members来比对新老成员数量大小
最后，如果数据都同步完了，那么就可以停止复制，切换应用了
- Rolling Duplication Upgrade
这个方法主要描述的是，如果在不减少原来group数量的同时，构建新group
因为很多时候，multi-primary都在提供业务，是不允许减少节点的
该处理方法是：
- 部署合适数量成员的新group
- 对老group的成员进行备份
- 使用这个备份进行升级，参考 Section 18.6.2.5, “Group Replication Upgrade with mysqlbackup”
- 使用升级好server进行构建一个新的group
- 创建一个异步复制通道在新老group中。老的group的priamry作为master，新的group成员作为GTID-based slave
一旦新老group直接的数据差异越来越小，小到很快就能追上，那么就可以重新指向业务application
18.6.2.5 Group Replication Upgrade with mysqlbackup
步骤如下：
- 使用mysqlbackup来备份老group的成员
- 部署一个跟备份一样版本的成员实例
- 使用mysqlbackup来恢复一个新成员实例
- 在新实例上升级
