点击参与 GreatSQL 8.0.32-26 文档捉虫~~~

GreatSQL社区

搜索

[已解决] GreatSQL-8.0.25升级到GreatSQL-8.0.32

314 1 2024-7-23 10:26
GreatSQL-8.0.25升级到GreatSQL-8.0.32

8.0.26由于新增 group_replication_view_change_uuid,不支持从8.0.25平滑升级, 这个参数在8.4的版本中又弃用了...
分2种情况

第一种. GreatSQL-8.0.25升级到GreatSQL-8.0.32( 升级后 group_replication_communication_stack 采用mysql协议)
mysql-shell版本8.0.32,其他版本未测试


步骤概况:
1.主节点设置read_only后,停止MGR集群所有节点(先从后主)


2.修改my.cnf配置文件的“basedir”,将其指向8.0.32版本的二进制安装目录


3.若配置systemd启动命令不是指向8.0.32版本的也要修改指向8.0.32版本


4.启动所有节点(先主后从,注意配置文件中设置这个: group_replication_bootstrap_group = OFF)
这个时候，因为前面关闭了所有节点，所以此时MGR集群是不会自动恢复的，需要手动恢复


5.用mysql shell连接MGR集群的主节点

  2. /usr/local/mysql-shell/bin/mysqlsh --uri mgr@192.168.0.206:3306
复制代码



6.执行dba.rebootClusterFromCompleteOutage(注意参数)命令 恢复集群,使用mysql协议来启动集群

  2. select cluster_name from mysql_innodb_cluster_metadata.clusters; 使用这个查看当前集群名字
  3. dba.rebootClusterFromCompleteOutage('test-cmdb-MGR',{switchCommunicationStack: "mysql", localAddress:"192.168.0.206:3306"})
复制代码


7. 启动成功后,登录mysql这时查看是这个样子的
注意grLocal, 非主节点的信息没有更新,还是原来xcom的端口,这个是个坑,会导致下次dba.rebootClusterFromCompleteOutage()的时候起不来...还得加上
switchCommunicationStack: "mysql"
并且实例重启后会自动将data目录下的mysqld-auto.cnf里的group_replication_group_seeds等参数改成原来xcom协议的端口


  2. MySQL  192.168.0.206:3306  JS >\sql select * from mysql_innodb_cluster_metadata.instances;
  3. +-------------+--------------------------------------+------------------+--------------------------------------+------------------+----------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
  4. | instance_id | cluster_id                           | address          | mysql_server_uuid                    | instance_name    | addresses                                                                                          | attributes                                                                                                                                           | description |
  5. +-------------+--------------------------------------+------------------+--------------------------------------+------------------+----------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
  6. |           1 | 03434515-850a-11ee-aebd-ac1f6bc67fd6 | 192.168.0.206:3306 | 743c0a30-8504-11ee-9aa8-ac1f6bc67fd6 | 192.168.0.206:3306 | {"grLocal": "192.168.0.206:3306", "mysqlClassic": "192.168.0.206:3306"}                                | {"server_id": 168952014, "recoveryAccountHost": "%", "recoveryAccountUser": "mysql_innodb_cluster_168952014"}                                        | NULL        |
  7. |           4 | 03434515-850a-11ee-aebd-ac1f6bc67fd6 | 192.168.0.207:3306 | 7795de1e-8504-11ee-aee0-ac1f6bc61230 | 192.168.0.207:3306 | {"grLocal": "192.168.0.207:33069", "mysqlClassic": "192.168.0.207:3306"}                               | {"joinTime": "2024-07-18 03:24:07.170", "server_id": 168952015, "recoveryAccountHost": "%", "recoveryAccountUser": "mysql_innodb_cluster_168952015"} | NULL        |
  8. |           5 | 03434515-850a-11ee-aebd-ac1f6bc67fd6 | 192.168.0.208:3306 | 789a8466-8504-11ee-a244-ac1f6bc6900e | 192.168.0.208:3306 | {"grLocal": "192.168.0.208:33069", "mysqlClassic": "192.168.0.208:3306"}                               | {"joinTime": "2024-07-18 03:30:48.181", "server_id": 168952016, "recoveryAccountHost": "%", "recoveryAccountUser": "mysql_innodb_cluster_168952016"} | NULL        |
  9. +-------------+--------------------------------------+------------------+--------------------------------------+------------------+----------------------------------------------------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
  10. 3 rows in set (0.00 sec)
复制代码


8. 回到mysql shell连接MGR集群的主节点的窗口
确认当前mysql shell连接的是主节点



  2. var c = dba.getCluster()
  3. c.status()
  4. MySQL  192.168.0.206:3306  JS > c.status()
  5. {
  6.     "clusterName": "test-cmdb-MGR",
  7.     "defaultReplicaSet": {
  8.         "name": "default",
  9.         "primary": "192.168.0.206:3306",
  10.         "ssl": "DISABLED",
  11.         "status": "OK",
  12.         "statusText": "Cluster is ONLINE and can tolerate up to ONE failure.",
  13.         "topology": {
  14.             "192.168.0.206:3306": {
  15.                 "address": "192.168.0.206:3306",
  16.                 "memberRole": "PRIMARY",
  17.                 "mode": "R/W",
  18.                 "readReplicas": {},
  19.                 "replicationLag": "applier_queue_applied",
  20.                 "role": "HA",
  21.                 "status": "ONLINE",
  22.                 "version": "8.0.32"
  23.             },
  24.             "192.168.0.207:3306": {
  25.                 "address": "192.168.0.207:3306",
  26.                 "memberRole": "SECONDARY",
  27.                 "mode": "R/O",
  28.                 "readReplicas": {},
  29.                 "replicationLag": "applier_queue_applied",
  30.                 "role": "HA",
  31.                 "status": "ONLINE",
  32.                 "version": "8.0.32"
  33.             },
  34.             "192.168.0.208:3306": {
  35.                 "address": "192.168.0.208:3306",
  36.                 "memberRole": "SECONDARY",
  37.                 "mode": "R/O",
  38.                 "readReplicas": {},
  39.                 "replicationLag": "applier_queue_applied",
  40.                 "role": "HA",
  41.                 "status": "ONLINE",
  42.                 "version": "8.0.32"
  43.             }
  44.         },
  45.         "topologyMode": "Single-Primary"
  46.     },
  47.     "groupInformationSourceMember": "192.168.0.206:3306"
  48. }
复制代码


执行以下命令分别将2个SECONDARY节点移除并重新加入集群(这个动作基本会很快完成.不需要重建数据.)


  2. c.removeInstance('192.168.0.207:3306')
  3. c.addInstance('192.168.0.207:3306',{localAddress: "192.168.0.207:3306"})

  5. #确认集群节点状态
  6. c.status()

  8. c.removeInstance('192.168.0.208:3306')
  9. c.addInstance('192.168.0.208:3306',{localAddress: "192.168.0.208:3306"})
  10. 确认集群节点状态
  11. c.status()
复制代码


这俩动作输出如下:


  2. MySQL  192.168.0.206:3306  JS > c.removeInstance('192.168.0.207:3306')
  3. The instance will be removed from the InnoDB Cluster.

  5. * Waiting for instance '192.168.0.207:3306' to synchronize with the primary...
  6. ** Transactions replicated  ############################################################  100%

  8. * Instance '192.168.0.207:3306' is attempting to leave the cluster...

  10. The instance '192.168.0.207:3306' was successfully removed from the cluster.

  12. MySQL  192.168.0.206:3306  JS >
  13. MySQL  192.168.0.206:3306  JS > c.addInstance('192.168.0.207:3306',{localAddress: "192.168.0.207:3306"});
  14. The safest and most convenient way to provision a new instance is through automatic clone provisioning, which will completely overwrite the state of '192.168.0.207:3306' with a physical snapshot from an existing cluster member. To use this method by default, set the 'recoveryMethod' option to 'clone'.

  16. The incremental state recovery may be safely used if you are sure all updates ever executed in the cluster were done with GTIDs enabled, there are no purged transactions and the new instance contains the same GTID set as the cluster or a subset of it. To use this method by default, set the 'recoveryMethod' option to 'incremental'.

  18. Incremental state recovery was selected because it seems to be safely usable.

  20. Validating instance configuration at 192.168.0.207:3306...

  22. This instance reports its own address as 192.168.0.207:3306

  24. Instance configuration is suitable.
  25. A new instance will be added to the InnoDB Cluster. Depending on the amount of
  26. data on the cluster this might take from a few seconds to several hours.

  28. Adding instance to the cluster...

  30. Monitoring recovery process of the new cluster member. Press ^C to stop monitoring and let it continue in background.
  31. Incremental state recovery is now in progress.

  33. * Waiting for distributed recovery to finish...
  34. NOTE: '192.168.0.207:3306' is being recovered from '192.168.0.208:3306'
  35. * Distributed recovery has finished

  37. The instance '192.168.0.207:3306' was successfully added to the cluster.
复制代码



9. 调整完毕后,登录mysql这时查看是这个样子的(grLocal 改过来了(一开始想直接改数据里的字段值来着,但是不知道是否有其他坑.))



  2. MySQL  192.168.0.206:3306  JS >\sql select * from mysql_innodb_cluster_metadata.instances;
  3. +-------------+--------------------------------------+--------------------+--------------------------------------+------------------+---------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
  4. | instance_id | cluster_id                           | address            | mysql_server_uuid                    | instance_name    | addresses                                                           | attributes                                                                                                                                                   | description |
  5. +-------------+--------------------------------------+--------------------+--------------------------------------+------------------+---------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
  6. |           6 | 03434515-850a-11ee-aebd-ac1f6bc67fd6 | 192.168.0.207:3306 | 7795de1e-8504-11ee-aee0-ac1f6bc61230 | 192.168.0.207:3306 | {"grLocal": "192.168.0.207:3306", "mysqlClassic": "192.168.0.207:3306"} | {"joinTime": "2024-07-22 02:48:18.084", "server_id": 168952015, "recoveryAccountHost": "%", "recoveryAccountUser": "mysql_innodb_cluster_168952015"} | NULL        |
  7. |           7 | 03434515-850a-11ee-aebd-ac1f6bc67fd6 | 192.168.0.208:3306 | 789a8466-8504-11ee-a244-ac1f6bc6900e | 192.168.0.208:3306 | {"grLocal": "192.168.0.208:3306", "mysqlClassic": "192.168.0.208:3306"} | {"joinTime": "2024-07-22 02:50:02.789", "server_id": 168952016, "recoveryAccountHost": "%", "recoveryAccountUser": "mysql_innodb_cluster_168952016"} | NULL        |
  8. |           8 | 03434515-850a-11ee-aebd-ac1f6bc67fd6 | 192.168.0.206:3306 | 743c0a30-8504-11ee-9aa8-ac1f6bc67fd6 | 192.168.0.206:3306 | {"grLocal": "192.168.0.206:3306", "mysqlClassic": "192.168.0.206:3306"} | {"joinTime": "2024-07-22 03:01:54.720", "server_id": 168952014, "recoveryAccountHost": "%", "recoveryAccountUser": "mysql_innodb_cluster_168952014"} | NULL        |
  9. +-------------+--------------------------------------+------------------+--------------------------------------+------------------+---------------------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------+-------------+
  10. 3 rows in set (0.00 sec)
复制代码


10. 上面都改完了后,修改mysql配置文件里的配置和实例里参数配置.
几个节点都要改,配置要各自对应起来.


  2. SET PERSIST group_replication_communication_stack="MYSQL";
  3. SET PERSIST group_replication_local_address="192.168.0.206:3306";
  4. SET PERSIST group_replication_group_seeds="192.168.0.207:3306,192.168.0.208:3306";
复制代码


检查包括my.cnf 和 data目录下的mysqld-auto.cnf 是否都改过来了.
group_replication_group_seeds这个参数my.cnf里面可以不用配置了.

11.检查一下


  2. MySQL  192.168.0.206:3306  JS >\sql SELECT * FROM performance_schema.replication_group_members;
  3. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
  4. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
  5. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
  6. | group_replication_applier | 743c0a30-8504-11ee-9aa8-ac1f6bc67fd6 | 192.168.0.206 |        3306 | ONLINE       | PRIMARY     | 8.0.32         | MySQL                      |
  7. | group_replication_applier | 7795de1e-8504-11ee-aee0-ac1f6bc61230 | 192.168.0.207 |        3306 | ONLINE       | SECONDARY   | 8.0.32         | MySQL                      |
  8. | group_replication_applier | 789a8466-8504-11ee-a244-ac1f6bc6900e | 192.168.0.208 |        3306 | ONLINE       | SECONDARY   | 8.0.32         | MySQL                      |
  9. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
  10. 3 rows in set (0.00 sec)

  12. #或者 MySQL shell中执行一下这个看看
  13. dba.getCluster().status({extended:1})
复制代码


12. 完工.


第二种. GreatSQL-8.0.25升级到GreatSQL-8.0.32( 升级后group_replication_communication_stack依旧采用xcom协议)

mysql-shell版本8.0.32,其他版本未测试
步骤概况:
1.主节点设置read_only后,停止MGR集群所有节点(先从后主)

2.修改my.cnf配置文件的“basedir”,将其指向8.0.32版本的二进制安装目录

3.若配置systemd启动命令不是指向8.0.32版本的也要修改指向8.0.32版本

4.启动所有节点(先主后从,注意配置文件中设置这个: group_replication_bootstrap_group = OFF)
这个时候，因为前面关闭了所有节点，所以此时MGR集群是不会自动恢复的，需要手动恢复

5.用mysql shell连接MGR集群的主节点



  2. /usr/local/mysql-shell/bin/mysqlsh --uri mgr@192.168.0.206:3306
复制代码


6.执行dba.rebootClusterFromCompleteOutage(注意参数)命令 恢复集群,使用xcom协议来启动集群
使用这个查看当前集群名字


  2. select cluster_name from mysql_innodb_cluster_metadata.clusters;
  3. dba.rebootClusterFromCompleteOutage('test-cmdb-MGR',{switchCommunicationStack: "xcom", localAddress: '192.168.0.206:33069'})
复制代码


注意: mgr的通信端口默认为: port * 10 + 1, 如果是单机多实例的场景下,当多个实例默认端口都是3306时(通过bind绑定不同的ip到各实例上,端口相同), 这个localAddress必须显式的指定.
localAddress 是个重要的参数,在很多命令里都可能会用到.
switchCommunicationStack: "xcom" 在这里应该不用加也可以.

7. 修改配置,检查包括my.cnf 和 data目录下的mysqld-auto.cnf 是否都配置正确
如果使用非默认端口,以下几个参数都要在配置文件中显式的配置,


  2. SET PERSIST group_replication_communication_stack="XCOM";
  3. SET PERSIST group_replication_local_address="192.168.0.206:33069";
  4. SET PERSIST group_replication_group_seeds="192.168.0.207:33069,192.168.0.208:33069";
复制代码


8. 检查一下



  2. MySQL  192.168.0.206:3306  JS >\sql SELECT * FROM performance_schema.replication_group_members;
  3. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
  4. | CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
  5. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
  6. | group_replication_applier | 743c0a30-8504-11ee-9aa8-ac1f6bc67fd6 | 192.168.0.206 |        3306 | ONLINE       | PRIMARY     | 8.0.32         | XCom                       |
  7. | group_replication_applier | 7795de1e-8504-11ee-aee0-ac1f6bc61230 | 192.168.0.207 |        3306 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
  8. | group_replication_applier | 789a8466-8504-11ee-a244-ac1f6bc6900e | 192.168.0.208 |        3306 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
  9. +---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+----------------------------+
  10. 3 rows in set (0.00 sec)

  12. #或者 MySQL shell中执行一下这个看看
  13. dba.getCluster().status({extended:1})
复制代码


9. 完工.

总结:
1. mysql-shell 8.0.32的版本新部署mysql 8.0.32的cluster, 默认cluster 通讯协议采用mysql, 除非在创建集群时显式的指定 communicationStack:'xcom'


  2. dba.createCluster('test-cmdb-MGR',{communicationStack: 'xcom', localAddress: '192.168.0.206:33069', ipAllowlist: '192.168.0.0/16', groupSeeds: '192.168.0.207:33069, 192.168.0.208:33069'})
复制代码


2. 当通讯协议为xcom时,并且mgr通讯端口采用非默认方式,localAddress 必须显式指定.








全部回复(1)
只看楼主
yejr 2024-7-23 10:43:42
非常详细的升级过程，感谢分享
回复 采纳

举报

earl86

8

主题

0

博客

46

贡献

注册会员

Rank: 2

积分
74

助人为乐（铜）

发消息
互动与交流
社区活动
论坛问答
加入社区
贡献者指南
学习与应用
文章博客
文档资料
视频资料
常见问题
发现社区
社区准则
建议反馈
社区之星

合作电话：010-64087828

社区邮箱：greatsql@greatdb.com

社区公众号
社区小助手
QQ群
友情链接
万里数据库开源中国墨天轮开放原子开源基金会OpenEuler
©2022 GreatSQL All Rights Reserved. ( 京ICP备06057874号 )
GMT+8, 2024-11-21 20:32 , Processed in 0.019943 second(s), 12 queries , Redis On.
快速回复 返回顶部 返回列表