Contents
  1. 1. 18.6.1 Group Replication Offline Upgrade
  2. 2. 18.6.2 Group Replication Online Upgrade
    1. 2.1. 18.6.2.1 Online Upgrade Considerations
    2. 2.2. 18.6.2.2 Combining Group Replication Versions
    3. 2.3. 18.6.2.3 Upgrading a Group Replication Member
    4. 2.4. 18.6.2.4 Group Replication Online Upgrade Methods
    5. 2.5. 18.6.2.5 Group Replication Upgrade with mysqlbackup

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可能会存在着不兼容性,这一章主要描述不同组合的最佳实践

如何查看版本

1
2
3
4
5
6
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就可以处理事务,所以该模式下人工配置哪个可以写,哪个不可以写是非常重要的步骤

1
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来恢复一个新成员实例
  • 在新实例上升级
Contents
  1. 1. 18.6.1 Group Replication Offline Upgrade
  2. 2. 18.6.2 Group Replication Online Upgrade
    1. 2.1. 18.6.2.1 Online Upgrade Considerations
    2. 2.2. 18.6.2.2 Combining Group Replication Versions
    3. 2.3. 18.6.2.3 Upgrading a Group Replication Member
    4. 2.4. 18.6.2.4 Group Replication Online Upgrade Methods
    5. 2.5. 18.6.2.5 Group Replication Upgrade with mysqlbackup

幸福,不在于得到的多

而在于计较的少