MySQL MGR从5.7滚动升级至8.0

Posted 2021-08-04 老叶茶馆_

内容提纲

• 01、问题背景

• 02、MGR支持5.7升级到8.0么？怎么做？

• 03、MGR 5.7和MGR 8.0的对比

• 04、相关说明以及部分命令

• • 4.1 关于新老版本的加入顺序问题

  • 4.2 关于mysql 8.0新版本的一个细节

01、问题背景

前几天遇到了一个MGR 5.7版本的bug，报错信息如下:

mysql> update nm2domain set status=1 where db_domain_info_id=1316542 and id=1210974;
ERROR 3101 (HY000): Plugin instructed the server to rollback the current transaction.

我的运行环境：MGR 5.7版本、多主环境。

在执行上面一条更新SQL的时候，发现了上述报错，这条数据在MGR的每个节点上都进行了查看，数据都是有的。

经过排查以及咨询行业内的大佬，最终将问题根因缩小到下面2种情况：

• 1、MGR多主模式下的认证错误

• 2、怀疑是MySQL5.7版本MGR的一个bug

解决方案：将线上的MGR集群从多主模式切换为单主模式，然后再切回多主模式，问题得到了解决。

基于这个问题，最近计划将MGR的版本从MySQL5.7升级到MySQL8.0，今晚抽空在线上环境中测试了一下MGR的滚动升级，这里将部分结论和过程记录一下。

02、MGR支持5.7升级到8.0么？怎么做？

这里我先说结论，测试的结果是：支持升级。

升级的方案：

如果你是单主模式的MGR集群：

• 1、依次升级MGR的Secondary节点。注意，这里建议是新增一个MySQL8.0的节点，然后下掉一个MySQL5.7的节点。直到集群中只有Primary节点是MySQL5.7版本。

• 2、升级MGR的Primary节点。在Primary节点上执行stop group_replication,触发MGR的自动切换，此时会自动选择一个8.0版本的MySQL节点作为新的Primary。

• 3、升级旧的Primary节点为MySQL8.0版本，并重新加入到集群中。

如果你是多主模式的MGR集群：依次使用MySQL 8.0节点代替MySQL 5.7的节点即可。

03、MGR 5.7和MGR 8.0的对比

在MGR5.7中，使用下面语句查看MGR成员：

localhost.(none)>SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
| group_replication_applier | 00a6598b-d80d-11eb-98e8-70e28405e238 | 10.69.2.64  |        1234 | ONLINE       |
| group_replication_applier | 0f5765ad-d80d-11eb-a3f7-70e28405e217 | 10.69.2.66  |        1234 | ONLINE       |
| group_replication_applier | 1a17875e-d815-11eb-81d8-6c92bf07cfcb | 10.69.6.119 |        1234 | ONLINE       |
| group_replication_applier | c3a8a71d-d80c-11eb-afdd-70e28405e29b | 10.69.2.203 |        1234 | ONLINE       |
+---------------------------+--------------------------------------+-------------+-------------+--------------+
4 rows in set (0.00 sec)

在MySQL8.0中，MGR成员的信息更加丰富，下面分别是多主模式和单主模式下的MGR成员：

多主模式：

localhost.(none)>SELECT * FROM performance_schema.replication_group_members;
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 00a6598b-d80d-11eb-98e8-70e28405e238 | 10.69.2.64  |        1234 | ONLINE       | PRIMARY     | 5.7.24         |
| group_replication_applier | 0f5765ad-d80d-11eb-a3f7-70e28405e217 | 10.69.2.66  |        1234 | ONLINE       | PRIMARY     | 8.0.20         |
| group_replication_applier | 1a17875e-d815-11eb-81d8-6c92bf07cfcb | 10.69.6.119 |        1234 | ONLINE       | PRIMARY     | 8.0.20         |
| group_replication_applier | c3a8a71d-d80c-11eb-afdd-70e28405e29b | 10.69.2.203 |        1234 | ONLINE       | PRIMARY     | 5.7.24         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
4 rows in set (0.00 sec)

集群角色只有Primary字眼。

单主模式：

localhost.(none)>SELECT * FROM performance_schema.replication_group_members;       
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
| group_replication_applier | 00a6598b-d80d-11eb-98e8-70e28405e238 | 10.69.2.64  |        1234 | ONLINE       | SECONDARY   | 5.7.24         |
| group_replication_applier | 0f5765ad-d80d-11eb-a3f7-70e28405e217 | 10.69.2.66  |        1234 | ONLINE       | SECONDARY   | 8.0.20         |
| group_replication_applier | 1a17875e-d815-11eb-81d8-6c92bf07cfcb | 10.69.6.119 |        1234 | ONLINE       | SECONDARY   | 8.0.20         |
| group_replication_applier | c3a8a71d-d80c-11eb-afdd-70e28405e29b | 10.69.2.203 |        1234 | ONLINE       | PRIMARY     | 5.7.24         |
+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+
4 rows in set (0.00 sec)

集群角色有Primary字样和Secondary字样。

可以看到，相比MGR5.7，MGR 8.0多了两个关键的列，member_role和member_version,分别代表成员在集群中的角色和成员的MySQL版本。

从上面的member version中不难看出，MGR是兼容不同的版本在同一个集群出现的。

04、相关说明以及部分命令

测试的过程中，发现了2个有意思的现象：

4.1 关于新老版本的加入顺序问题

如果你的集群中都是MySQL5.7版本的成员，此时加入MySQL8.0版本的成员一切正常；

如果你的集群中有MySQL5.7版本的成员，同时又有MySQL8.0版本的成员，那么你加入MySQL8.0版本的成员不会报错，而加入MySQL5.7版本的成员会报错。报错信息如下：

2021-06-28T23:43:42.487492+08:00 0 [Note] Plugin group_replication reported: 'XCom protocol version: 3'
2021-06-28T23:43:42.487550+08:00 0 [Note] Plugin group_replication reported: 'XCom initialized and ready to accept incoming connections on port 12340'
2021-06-28T23:43:45.939855+08:00 0 [ERROR] Plugin group_replication reported: 'Member version is incompatible with the group'

4.2 关于MySQL 8.0新版本的一个细节

当MySQL8.0的成员加入到MySQL5.7的成员组成的MGR集群中时，即使配置了多主模式，首次加入后，MySQL8.0的节点的super_read_only=on（当然，跟版本有点关系，高版本的已经修复）,也就是说，MGR不会自动将这个成员设置为可写模式，需要你手工设置。

这个配置的说明在官方文档中是有迹可循的：

When an upgraded member joins a group which has any member running an earlier MySQL Server version, the upgraded member joins with super_read_only=on. This ensures that no writes are made to upgraded members until all members are running the newer version. In a multi-primary mode group, when the upgrade has been completed successfully and the group is ready to process transactions, members that are intended as writeable primaries must be set to read-write mode. From MySQL 8.0.17, when all members of a group have been upgraded to the same release, they all change back to read-write mode automatically. For earlier releases you must set each member manually to read-write mode. 

具体位置可以参考：

• https://dev.mysql.com/doc/refman/8.0/en/group-replication-upgrading-member.html

• https://dev.mysql.com/doc/refman/8.0/en/group-replication-online-upgrade-methods.html

新增MGR节点配置：

-----新节点配置文件内容--------
# Group Replication
transaction-isolation = READ-COMMITTED
binlog_checksum = NONE
master_info_repository = TABLE
relay_log_info_repository = TABLE
plugin-load = group_replication.so
transaction_write_set_extraction = XXHASH64
loose-group_replication_group_name = "xxxx"
loose-group_replication_start_on_boot = OFF
loose-group_replication_local_address = 'xxx.xxx.xxx.xxx:12340'
loose-group_replication_group_seeds = ''
group_replication_ip_whitelist = '10.0.0.0/8'
loose-group_replication_bootstrap_group = OFF
loose-group_replication_single_primary_mode = OFF
loose-group_replication_enforce_update_everywhere_checks = ON 
loose-group_replication_transaction_size_limit = 52428800 
# loose-group_replication_unreachable_majority_timeout
report_host = 'xxx.xxx.xxx.xxx'
report_port = 1234

新节点加入集群命令：

INSTALL PLUGIN group_replication SONAME 'group_replication.so';
change master to master_user='replica',master_password='xxxxxx' FOR CHANNEL 'group_replication_recovery';
start group_replication;

---

文章推荐：

• 技术分享 | MGR最佳实践(MGR Best Practice)

• 技术分享 | 万里数据库MGR Bug修复之路

• 金融应用场景下跨数据中心的MGR架构方案（2）

• 技术分享  | InnoDB Cluster+GreatSQL快速部署MGR集群，并实现读写分离和故障自动转移（超详细）

• 技术分享   | 利用GreatSQL部署MGR集群，并完成添加新节点 、滚动升级、切主（超详细）

• 《叶问》33期，MGR最佳配置参考，PFS里的监测指标要全开吗，mysqld进程占用内存过高怎么排查
  

• MySQL 复制延迟 Seconds_Behind_Master 究竟是如何计算的
  

• GreatSQL MGR优化参考
  

• GreatSQL，打造更好的MGR生态

---

扫码加入GreatSQL/MGR交流QQ群

点击文末“阅读原文”直达老叶专栏