怎么平滑的将MGR集群从GreatSQL-8.0.25升级到GreatSQL-8.0.32

从secondary节点开始，逐个节点inplace方式滚动升级

yejr 发表于 2023-11-28 13:51
从secondary节点开始，逐个节点inplace方式滚动升级

这个不停机升级好像不行，会报错：

2023-11-28T18:02:48.371253+08:00 0 [Warning] [MY-013737] [Repl] Plugin group_replication reported: 'This member joined a group on which all members do not support member actions, as such it did reset its member configuration to the default one.'
2023-11-28T18:02:48.374989+08:00 0 [Warning] [MY-013783] [Repl] This member joined a group on which all members do not support replication failover channels integration on Group Replication, as such it did reset its replication failover channels configuration to the default one.
2023-11-28T18:02:48.378290+08:00 0 [Warning] [MY-013426] [Repl] Plugin group_replication reported: 'Member version is read compatible with the group.'
2023-11-28T18:02:48.378372+08:00 0 [ERROR] [MY-013753] [Repl] Plugin group_replication reported: 'The member is configured with a group_replication_view_change_uuid option value 'AUTOMATIC' different from the group ''. The member will now exit the group.'
2023-11-28T18:02:48.378396+08:00 0 [Note] [MY-000000] [Repl] Plugin group_replication reported: 'Set cancelled_view_change true'


所以直接MGR集群停机逐个节点完成升级，然后再恢复MGR集群？

驭无殇1998 发表于 2023-11-28 14:07
这个不停机升级好像不行，会报错：

2023-11-28T18:02:48.371253+08:00 0 [Warning] [MY-013737] [Repl] P ...

抱歉，忘了这茬。

记得是8.0.26还是8.0.27，新增了group_replication_view_change_uuid，导致在跑MGR的情况下，不能实现滚动升级。

这种情况下，可以这么做：

1. 当前8.0.25版本的MGR对外停止服务；

2. 选取某个节点A作为donor，复制数据到新的8.0.32版本的节点B上；

3. 以节点B为primary节点，重新构建MGR集群。

yejr 发表于 2023-11-29 09:12
抱歉，忘了这茬。

记得是8.0.26还是8.0.27，新增了group_replication_view_change_uuid，导致在跑MGR的 ...

那我直接在现有的8.0.25的集群下，将所有节点都停机，然后单独每个节点根据文档直接升级到8.0.32，再重建可以嘛？不再另起新的8.0.32节点

驭无殇1998 发表于 2023-11-29 10:06
那我直接在现有的8.0.25的集群下，将所有节点都停机，然后单独每个节点根据文档直接升级到8.0.32，再重建 ...

你这种做法也是可以的，记得每个节点都要正确配置 group_replication_view_change_uuid 即可

yejr 发表于 2023-11-29 10:39
你这种做法也是可以的，记得每个节点都要正确配置 group_replication_view_change_uuid 即可 ...

经过测试，这种方法是可行的，具体的操作步骤为：
1.停止MGR集群所有节点
2.修改my.cnf配置文件的“basedir”,将其指向8.0.32版本的二进制安装目录
3.若配置systemd启动命令不是指向8.032版本的也要修改指向8.0.32版本
4.启动所有节点
这个时候，因为前面关闭了所有节点，所以此时MGR集群是不会自动恢复的，需要手动恢复
5.用mysqlsh连接MGR集群的主节点
6.执行dba.reboot_cluster_from_complete_outage()命令进行恢复即可
大致流程是这样，做之前最好备份一份主节点的数据，以防出现升级失败的情况。
目前平滑升级的办法尚未进行尝试，不过目前的停机升级办法也可以满足我的需求。

yejr 发表于 2023-11-29 10:39
你这种做法也是可以的，记得每个节点都要正确配置 group_replication_view_change_uuid 即可 ...

根据实际测试结果，升级完成后，如果未配置group_replication_view_change_uuid ，会自动设置为“AUTOMATIC”，然后使用mysqlsh恢复集群，这个值会自动出来。如果事先在配置文件配置了，则使用配置文件所配置的值

驭无殇1998 发表于 2023-11-30 16:45
经过测试，这种方法是可行的，具体的操作步骤为：
1.停止MGR集群所有节点
2.修改my.cnf配置文件的“based ...

赞，感谢分享

yejr 发表于 2023-12-1 09:23
赞，感谢分享

dba.rebootClusterFromCompleteOutage('cluster集群名',{switchCommunicationStack: "mysql"})  这个最好加上这个参数.