开始今天的文章之前，先简单介绍下GreatSQL吧：
GreatSQL是国产MySQL的一个重要分支，目前主推的是GreatSQL 8.0.25 和 GreatSQL 5.7.36，如果你的生产环境用到了MGR组复制技术，那升级GreatSQL可以提升你的用户体验，因为它在MGR方向做了很多性能改善。
我们线上有一套MGR开发环境，最近从社区MySQL5.7.24版本 升级到了GreatSQL5.7.36版本。目前运行一周，状态良好。这里，我整理了一下从MySQL 5.7社区版本升级到GreatSQL 5.7.36过程中的详细步骤。
01
升级方案
其实，MGR的升级方案比较简单，我们以一个3节点的MGR集群为例，它大致的升级流程如下图：
可以看到，整个过程是逐个节点进行滚动升级的，跟之前MGR版本从5.7升级到8.0是类似的。
MGR 5.7滚动升级MGR 8.0
02
操作步骤
社区版本MySQL MGR升级GreatSQL的MGR操作步骤如下：
停掉社区版MySQL 5.7.24 MGR集群中的一个MySQL节点，并保存数据目录下载GreatSQL 5.7.36软件包，并利用GreatSQL软件包和数据目录直接启动GreatSQL实例利用GreatSQL软件包自带的mysql_upgrade工具更新GreatSQL实例的metadata元信息，确保能够兼容MySQL5.7.24版本的数据目录将GreatSQL实例加入到MySQL MGR集群中校验无误后，重复上述过程，滚动升级社区版MySQL MGR的其他节点。以下是详细的参考步骤：
1、GreatSQL的软件包下载
软件包下载地址:https://gitee.com/GreatSQL/GreatSQL-Doc#https://gitee.com/GreatSQL/GreatSQL/releases/GreatSQL-5.7.36-39
需要注意的是，如果你下载5.7.36版本，需要注意操作系统要求：
Centos7：GreatSQL-5.7.36-39-Linux-glibc2.17-x86_64.tar.xz
Centos8：GreatSQL-5.7.36-39-Linux-glibc2.28-x86_64.tar.xz
2、线上MGR集群如下：
select * from performance_schema.replication_group_members; +---------------------------+--------------------------------------+--------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ | group_replication_applier | 0aefafeb-8352-11e9-897b-6c0b84be0e42 | 10.xx.xxx.xx | 5561 | ONLINE | | group_replication_applier | 27f732e0-e2e6-11ea-a18d-fa163ee85021 | 10.xx.xxx.xx | 5561 | ONLINE | | group_replication_applier | 49d1de7c-ea06-11eb-a73d-fa163e0815e1 | 10.xx.xxx.xx | 5561 | ONLINE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ 3 rows in set (0.00 sec)
使用stop group_replication命令，停掉社区版MySQL 5.7.24 MGR集群中的一个MySQL节点，并保存数据目录
3、利用GreatSQL软件包和MySQL数据目录启动GreatSQL实例。
此时配置文件可直接复用社区版MySQL版本的配置文件，过程中如果有报错，可根据报错修改配置文件参数即可，理论上是直接兼容的。
启动命令：
/usr/local/GreatSQL-5.7.36-glibc2.17/bin/mysqld_safe --defaults-file=/data1/mysql5561/my5561.cnf &
4、启动GreatSQL实例之后，执行start group_replication命令，将GreatSQL实例加入到社区版本的MGR组中（因为配置文件沿用了社区版的配置文件，所以可以直接加入），此时在社区版MySQL上查看MGR的组复制状态，可以看到Recovering字样
select * from performance_schema.replication_group_members; +---------------------------+--------------------------------------+--------------+-------------+--------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | +---------------------------+--------------------------------------+--------------+-------------+--------------+ | group_replication_applier | 0aefafeb-8352-11e9-897b-6c0b84be0e42 | 10.xx.xx.xxx | 5561 | ONLINE | | group_replication_applier | 27f732e0-e2e6-11ea-a18d-fa163ee85021 | 10.xx.xx.xxx | 5561 | ONLINE | | group_replication_applier | 49d1de7c-ea06-11eb-a73d-fa163e0815e1 | 10.xx.xx.xxx | 5561 | RECOVERING | +---------------------------+--------------------------------------+--------------+-------------+--------------+ 3 rows in set (0.01 sec)
说明实例已经进入到组复制的恢复阶段，正在应用重启这段时间内，过程中未执行的事务。
5、在GreatSQL实例中查看MGR状态，可以看到如下报错：
SELECT * FROM performance_schema.replication_group_membersG
ERROR 1682 (HY000): Native table 'performance_schema'.'replication_group_members' has the wrong structure
上述报错，说明GreatSQL软件包启动MySQL数据目录后，metadata元信息有部分不兼容，因此我们需要使用GreatSQL自带的工具mysql_upgrade来对metadata元信息进行升级。
6、利用mysql_upgrade升级metadata元信息
这里，需要重点mysql_upgrade的一个参数：
-s, --upgrade-system-tables
Only upgrade the system tables, do not try to upgrade the data.
upgrade-system-tables默认值是 FALSE，它代表默认情况下，只升级数据，不升级系统表，我们需要将它设置成True，否则升级完成之后，报错还会存在。
元信息升级命令如下：
/usr/local/GreatSQL-5.7.36-glibc2.17/bin/mysql_upgrade -uxxx -pxxx -P5561 -h 10.xx.xx.xxx mysql_upgrade: [Warning] Using a password on the command line interface can be insecure. Checking if update is needed. Checking server version. Running queries to upgrade MySQL server. Checking system database. mysql.columns_priv OK mysql.db OK mysql.engine_cost OK mysql.event OK mysql.func OK mysql.general_log OK .... Upgrade process completed successfully. Checking if update is needed.
7、重启实例，确保元信息升级后生效。
8、重新使用start group_replication命令加入MGR集群，并在GreatSQL上查看当前的组复制状态：
SELECT * FROM performance_schema.replication_group_members; +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+ | CHANNEL_NAME | MEMBER_ID | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+ | group_replication_applier | 0aefafeb-8352-11e9-897b-6c0b84be0e42 | 10.xx.xx.xxx | 5561 | ONLINE | PRIMARY | | group_replication_applier | 27f732e0-e2e6-11ea-a18d-fa163ee85021 | 10.xx.xx.xxx | 5561 | ONLINE | PRIMARY | | group_replication_applier | 49d1de7c-ea06-11eb-a73d-fa163e0815e1 | 10.xx.xx.xxx | 5561 | ONLINE | PRIMARY | +---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+ 3 rows in set (0.00 sec)
可以观察到一个细节，在社区版MySQL上查看MGR的组复制状态
只有5个字段，而在GreatSQL上查看MGR的组复制状态，有6个字段，多了个member_role字段，也就是成员角色字段。
其实，这跟MGR元信息表的字段数有关，在社区版本5.7上，本身这个表只有5个字段，官方文档地址如下：
https://dev.mysql.com/doc/refman/5.7/en/performance-schema-replication-group-members-table.html
GreatSQL对这个表做了改进，增加了member_role字段。
03
总结
社区版MySQL MGR集群升级GreatSQL集群的过程，相对平滑，但是升级过程中需要注意几个事项：
1、GreatSQL的版本和操作系统版本需要对应，否则安装过程中可能会遇到某些依赖包不存在的问题。遇到这种问题，可以去GreatSQL项目的ReadMe里面去找版本和安装包的匹配信息，或者查找对应的依赖包。
2、GreatSQL启动MySQL的数据目录之后，需要使用mysql_upgrade升级一次metadata元信息，否则加入组之后，无法查看当前的集群状态，另外升级过程中，需要指定update-system-table参数。
3、单纯对于MGR集群来说，最好使用8.0版本的MGR集群，可以避免一些坑。GreatSQL也推荐使用最新的8.0.25版本。如果你的集群是MySQL社区版5.7的MGR，可以先升级成GreatSQL的5.7版本的MGR，然后升级成GreatSQL的8.0.25的MGR
今天内容就到这里吧。
