组复制官方翻译六、Upgrading Group Replication

  1. 云栖社区>
  2. 博客>
  3. 正文

组复制官方翻译六、Upgrading Group Replication

兰春 2019-01-15 15:35:47 浏览963
展开阅读全文

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来恢复一个新成员实例
  • 在新实例上升级

网友评论

登录后评论
0/500
评论
兰春
+ 关注