GreatSQL社区原创内容未经受权不得随便应用，转载请分割小编并注明起源。

[toc]

本文介绍MGR的选主算法，以及当MGR集群中有多个不同版本混搭时，如何能力失常运行，有什么注意事项。

1. 选主算法

MGR运行在单主模式时，当产生主节点切换，就须要进行选主工作。多主模式下，所有节点都是主节点，就不须要选主了。

MGR的选主工作是主动的，每个节点都会参加。选主时会查看以后最新的组视图，对潜在的新主节点（各个备选节点）进行排序，最初选出最合适的那个作为新的主节点。

不同的MySQL版本选主算法略有不同，各节点选主时会依据以后的MySQL版本选主算法而决定，因而当MGR集群中有多个版本并存时，则此时MGR会做出调整，以便各个不同版本的节点都能就选主达成算法统一。

通常而言，选主算法的各个因素优先级程序如下：

依据MySQL版本号排序，低版本的优先级更高（因为要向下兼容）。如果是MySQL 8.0.17及以上版本，则优先依据补丁版本号排序（例如17、18、20）。如果是8.0.16及以下版本，则优先依据主版本号排序（例如5.7、8.0）。
版本号雷同的各节点则依据各节点的权重值排序，权重越高优先级也越高。节点的权重值可通过设置 group_replication_member_weight 选项来调整。这个选项是MySQL 8.0版本引入的，如果是5.7版本则不反对。
当版本号和节点权重值都一样时，再依据 server_uuid（或者说是 MEMBER_ID）排序（留神，不是 server_id），排在后面的优先级越高。MySQL Server在启动时，会生成一个随机的UUID值，其值记录在文件 datadir/auto.cnf 文件中，实际上能够在实例启动前，通过批改这个UUID值来扭转 server_uuid 的值，只有合乎UUID数据格式即可。因而，相当于是能够认为调整 server_uuid 以调整选主时节点的排序优先级。

从下面可知，当有MySQL 8.0和5.7的节点混搭运行MGR集群时，运行5.7版本的节点会优先被选中，其次再依据 group_replication_member_weight 抉择权重搞的节点，最初再依据 server_uuid 排序。

因而，运行MGR集群时最好各节点版本号雷同，选主规定就简略多了。

在MySQL 8.0中，通过查问 performance_schema.replication_group_members 表的MEMBER_ROLE 即可晓得哪个是主节点：

mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST  | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+| group_replication_applier | 4ebd3504-11d9-11ec-8f92-70b5e873a570 | 172.16.16.10 |        3306 | ONLINE       | PRIMARY     | 8.0.25         |  <---主节点| group_replication_applier | 549b92bf-11d9-11ec-88e1-70b5e873a570 | 172.16.16.11 |        3307 | ONLINE       | SECONDARY   | 8.0.25         || group_replication_applier | 5596116c-11d9-11ec-8624-70b5e873a570 | 172.16.16.12 |        3308 | ONLINE       | SECONDARY   | 8.0.25         |+---------------------------+--------------------------------------+--------------+-------------+--------------+-------------+----------------+

如果是在MySQL 5.7中，则须要通过查问 group_replication_primary_member 这个 status 能力晓得，比8.0麻烦。所以说，还是尽量应用MySQL 8.0来构建MGR集群。

在一个MySQL 5.7和8.0混搭的MGR集群中，从运行MySQL 8.0版本的节点上看到的状态是这样的：

mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+| group_replication_applier | af39db70-6850-11ec-94c9-00155d064000 | 172.16.16.13  |        3306 | ONLINE       | SECONDARY   | 8.0.25         || group_replication_applier | d9833e7e-6ecc-11ec-a3f6-d08e7908bcb1 | 172.16.16.10  |        3306 | ONLINE       | PRIMARY     | 5.7.36         || group_replication_applier | fe55e195-6ecc-11ec-a2e9-d08e7908bcb1 | 172.16.16.11  |        3306 | ONLINE       | SECONDARY   | 5.7.36         || group_replication_applier | ff19317f-6ecc-11ec-b17d-d08e7908bcb1 | 172.16.16.12  |        3306 | ONLINE       | SECONDARY   | 5.7.36         |+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+

能够看到，即使是运行MySQL 8.0版本的节点的 server_uuid 排序在后面，但在主动选主时，也不会被选中作为主节点。此外，运行MySQL 5.7版本的节点是无奈退出主节点运行MySQL 8.0的MGR集群的，会报告相似上面的谬误：

[ERROR] Plugin group_replication reported: 'Member version is incompatible with the group'

提醒版本不兼容。

2. 多版本兼容性

失常地，为了MGR的兼容性及性能，所有节点的MySQL版本最好保持一致。尤其是在多主模式下，各节点都提供写入服务，如果兼容性方面存在问题，则可能会导致MGR集群异样或写入异样。为了防止这种状况产生，新退出节点时，会和其余节点进行版本兼容性查看。

目前MGR反对3个通信协议版本号：5.7.14、8.0.16、8.0.27，这几个版本的次要变动有：

从5.7.14开始，反对消息压缩。
从8.0.16开始，反对音讯分片。
从8.0.27开始，反对在单主模式下，设置惟一的leader节点。

MGR集群中，各节点间的通信协议版本号必须统一，这样能力保障即便是MySQL版本号不统一，但MGR通信仍然不受影响。新退出节点的通信协议版本号必须高于以后集群中应用的通信协议版本。节点退出时会查看协定版本，并向其播送以后集群中应用的协定版本，如果能够兼容，则容许退出，否则会将其踢出。

当两个节点同时退出时，只有当两个节点的通信协议版本和集群兼容时，能力同时退出胜利。和以后集群不同协定版本的节点须要独自退出才行，例如：

一个应用8.0.16版本的实例能够胜利退出应用通信协议版本5.7.24的集群。
一个5.7.24实例无奈退出应用8.0.16的集群。
两个8.0.16实例无奈同时退出应用5.7.24的集群。
两个8.0.16实例能够同时退出应用8.0.16的集群。

如果有须要，还能够在线批改通信协议版本号，应用 group_replication_set_communication_protocol() 这个UDF即可（MySQL 8.0以上反对），例如：

mysql> select version();+-----------+| version() |+-----------+| 8.0.25-15 |  <-- 以后MySQL版本是8.0.25+-----------+1 row in set (0.00 sec)mysql> select group_replication_get_communication_protocol();+------------------------------------------------+| group_replication_get_communication_protocol() |+------------------------------------------------+| 8.0.16                                         |  <-- 以后MGR通信协议版本是8.0.16+------------------------------------------------+1 row in set (0.00 sec)mysql> select group_replication_set_communication_protocol('5.7.14');+-----------------------------------------------------------------------------------+| group_replication_set_communication_protocol('5.7.14')                            |  <-- 手动批改通信协议版本为5.7.14，能够胜利+-----------------------------------------------------------------------------------+| The operation group_replication_set_communication_protocol completed successfully |+-----------------------------------------------------------------------------------+mysql> select group_replication_set_communication_protocol('8.0.25');+-----------------------------------------------------------------------------------+| group_replication_set_communication_protocol('8.0.25')                            |+-----------------------------------------------------------------------------------+| The operation group_replication_set_communication_protocol completed successfully |  <-- 批改协定版本为8.0.25，接下来看看会产生什么+-----------------------------------------------------------------------------------+1 row in set (0.00 sec)mysql> select group_replication_get_communication_protocol();+------------------------------------------------+| group_replication_get_communication_protocol() |+------------------------------------------------+| 8.0.16                                         |  <-- 重置为8.0.16+------------------------------------------------+# 尝试批改为8.0.27，会报错mysql> select group_replication_set_communication_protocol('8.0.27');ERROR 1123 (HY000): Can't initialize function 'group_replication_set_communication_protocol'; 8.0.27 is not between 5.7.14 and 8.0.25

其实说这么多版本兼容性的话题，还不如一个简略的准则：让所有节点的版本号都统一。这样构建MGR集群更简略，节点间通信也不会被复杂化。

3. MGR 5.7滚动降级至8.0

MGR 5.7集群滚动降级至8.0能够参考这篇文章：MySQL MGR从5.7滚动降级至8.0，简言之，能够分为以下几步：

在现有MGR 5.7集群中，新增MySQL 8.0的Secondary节点。
一比一下线一个MySQL 5.7的Secondary节点。
如此往返，直到剩下最初一个MySQL 5.7的Primary节点。
再次上线一个MySQL 8.0的Secondary节点。
进行最初一个MySQL 5.7的Primary节点，这是会切换主节点，并且抉择其中一个MySQL 8.0节点作为新的Primary节点，这就实现降级了。

在这里实操演示大略的过程。

在MGR 5.7的集群中，减少一个MySQL 8.0的Secondary节点：

#在5.7节点上看节点状态#原生的MySQL 5.7 MGR看不到 MEMBER_ROLE 这列#这是GreatSQL 5.7新增的个性mysql> select * from performance_schema.replication_group_members;+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+| group_replication_applier | c8ec34c4-78fc-11ec-864a-111111111111 | 127.0.0.1   |        4306 | ONLINE       | PRIMARY     || group_replication_applier | c8ec34c4-78fc-11ec-864a-222222222222 | 127.0.0.1   |        4307 | ONLINE       | SECONDARY   || group_replication_applier | c8ec34c4-78fc-11ec-864a-333333333333 | 127.0.0.1   |        4308 | ONLINE       | SECONDARY   || group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888333 | 127.0.0.1   |        3309 | ONLINE       | SECONDARY   |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+#在8.0节点上看+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| group_replication_applier | c8ec34c4-78fc-11ec-864a-111111111111 | 127.0.0.1   |        4306 | ONLINE       | PRIMARY     | 5.7.36         || group_replication_applier | c8ec34c4-78fc-11ec-864a-222222222222 | 127.0.0.1   |        4307 | ONLINE       | SECONDARY   | 5.7.36         || group_replication_applier | c8ec34c4-78fc-11ec-864a-333333333333 | 127.0.0.1   |        4308 | ONLINE       | SECONDARY   | 5.7.36         || group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888333 | 127.0.0.1   |        3309 | ONLINE       | SECONDARY   | 8.0.25         |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

当初，利用MySQL Shell删除一个旧节点：

c.removeInstance('127.0.0.1:4308');The instance will be removed from the InnoDB cluster. Depending on the instancebeing the Seed or not, the Metadata session might become invalid. If so, pleasestart a new session to the Metadata Storage R/W instance.Instance '127.0.0.1:4308' is attempting to leave the cluster...WARNING: On instance '127.0.0.1:4308' configuration cannot be persisted since MySQL version 5.7.36 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please set the 'group_replication_start_on_boot' variable to 'OFF' in the server configuration file, otherwise it might rejoin the cluster upon restart.WARNING: Instance '127.0.0.1:4306' cannot persist configuration since MySQL version 5.7.36 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please use the dba.configureLocalInstance() command locally to persist the changes.The instance '127.0.0.1:4308' was successfully removed from the cluster.

之后再查看节点状态：

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| group_replication_applier | c8ec34c4-78fc-11ec-864a-111111111111 | 127.0.0.1   |        4306 | ONLINE       | PRIMARY     | 5.7.36         || group_replication_applier | c8ec34c4-78fc-11ec-864a-222222222222 | 127.0.0.1   |        4307 | ONLINE       | SECONDARY   | 5.7.36         || group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888333 | 127.0.0.1   |        3309 | ONLINE       | SECONDARY   | 8.0.25         |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

如此往返，直到只剩最初一个5.7节点：

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| group_replication_applier | c8ec34c4-78fc-11ec-864a-111111111111 | 127.0.0.1   |        4306 | ONLINE       | PRIMARY     | 5.7.36         || group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888333 | 127.0.0.1   |        3309 | ONLINE       | SECONDARY   | 8.0.25         || group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888444 | 127.0.0.1   |        3310 | ONLINE       | SECONDARY   | 8.0.25         || group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888555 | 127.0.0.1   |        3311 | ONLINE       | SECONDARY   | 8.0.25         |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

敞开最初一个5.7节点，会主动切换主节点：

 MySQL  127.0.0.1:4306 ssl  JS > c.removeInstance('127.0.0.1:4306');The instance will be removed from the InnoDB cluster. Depending on the instancebeing the Seed or not, the Metadata session might become invalid. If so, pleasestart a new session to the Metadata Storage R/W instance.Instance '127.0.0.1:4306' is attempting to leave the cluster...WARNING: On instance '127.0.0.1:4306' configuration cannot be persisted since MySQL version 5.7.36 does not support the SET PERSIST command (MySQL version >= 8.0.11 required). Please set the 'group_replication_start_on_boot' variable to 'OFF' in the server configuration file, otherwise it might rejoin the cluster upon restart.The instance '127.0.0.1:4306' was successfully removed from the cluster.

之后能够看到5.7节点全副下线了，只剩下8.0节点：

+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+| group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888333 | 127.0.0.1   |        3309 | ONLINE       | PRIMARY     | 8.0.25         || group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888444 | 127.0.0.1   |        3310 | ONLINE       | SECONDARY   | 8.0.25         || group_replication_applier | c8ec34c4-78fc-11ec-864a-888888888555 | 127.0.0.1   |        3311 | ONLINE       | SECONDARY   | 8.0.25         |+---------------------------+--------------------------------------+-------------+-------------+--------------+-------------+----------------+

查看切换过程：

2022-01-20T22:19:10.753644+08:00 0 [Warning] [MY-011499] [Repl] Plugin group_replication reported: 'Members removed from the group: 127.0.0.1:4306'2022-01-20T22:19:10.753648+08:00 0 [System] [MY-011500] [Repl] Plugin group_replication reported: 'Primary server with address 127.0.0.1:4306 left the group. Electing new Primary.'2022-01-20T22:19:10.753705+08:00 0 [Note] [MY-011071] [Repl] Plugin group_replication reported: 'handle_leader_election_if_needed is activated,suggested_primary:'2022-01-20T22:19:10.754747+08:00 0 [Note] [MY-013519] [Repl] Plugin group_replication reported: 'Elected primary member gtid_executed: 082b900b-79d5-11ec-8fe2-00155d064000:1-32, 36ab409a-79d6-11ec-9cd5-00155d064000:1-37'2022-01-20T22:19:10.754790+08:00 0 [Note] [MY-013519] [Repl] Plugin group_replication reported: 'Elected primary member applierchannel received_transaction_set: 082b900b-79d5-11ec-8fe2-00155d064000:1-32, 36ab409a-79d6-11ec-9cd5-00155d064000:1-37'2022-01-20T22:19:11.754969+08:00 0 [System] [MY-011507] [Repl] Plugin group_replication reported: 'A new primary with address yejr.run:3309 was elected. The new primary will execute all previous group transactions before allowing writes.'2022-01-20T22:19:11.755803+08:00 92 [System] [MY-011566] [Repl] Plugin group_replication reported: 'Setting super_read_only=OFF.'2022-01-20T22:19:12.752517+08:00 0 [Note] [MY-011735] [Repl] Plugin group_replication reported: '[GCS] Failure reading from fd=53 n=0'2022-01-20T22:19:12.755961+08:00 0 [System] [MY-011503] [Repl] Plugin group_replication reported: 'Group membership changed to yejr.run:3309, 127.0.0.1:3310, 127.0.0.1:3311 on view 16426721489193731:9.'2022-01-20T22:19:12.756296+08:00 91 [System] [MY-011566] [Repl] Plugin group_replication reported: 'Setting super_read_only=OFF.'2022-01-20T22:19:12.756744+08:00 91 [System] [MY-011510] [Repl] Plugin group_replication reported: 'This server is working as primary member.'2022-01-20T22:19:12.756787+08:00 30 [Note] [MY-011485] [Repl] Plugin group_replication reported: 'Primary had applied all relaylogs, disabled conflict detection.'

这就实现滚动降级了。

4. 小结

本文介绍了MGR集群中是如何进行选主的，当有5.7、8.0版本混合时的兼容性，以及如何把MGR 5.7滚动降级到8.0。最初多说一句，哪怕是不必MGR，8.0绝对5.7还是有很多企业级个性，5.6、5.7也只能是过渡版本，最终还是强烈建议降级到8.0版本。

参考资料、文档

MySQL 8.0 Reference Manual
数据库内核开发 - 温正湖
Group Replication原理 - 宋利兵

免责申明

因集体程度无限，专栏中不免存在错漏之处，请勿间接复制文档中的命令、办法间接利用于线上生产环境。请读者们务必先充沛了解并在测试环境验证通过前方可正式施行，防止造成生产环境的毁坏或侵害。

Enjoy GreatSQL :)

文章举荐：

GreatSQL季报（2021.12.26）

https://mp.weixin.qq.com/s/FZ...

技术分享|sysbench 压测工具用法浅析

https://mp.weixin.qq.com/s/m1...

故障剖析 | linux 磁盘io利用率高，剖析的正确姿态

https://mp.weixin.qq.com/s/7c...

技术分享|闪回在MySQL中的实现和改良

https://mp.weixin.qq.com/s/6j...

万答#20，索引下推如何进行数据过滤

https://mp.weixin.qq.com/s/pt...

对于 GreatSQL

GreatSQL是由万里数据库保护的MySQL分支，专一于晋升MGR可靠性及性能，反对InnoDB并行查问个性，是实用于金融级利用的MySQL分支版本。

Gitee:

https://gitee.com/GreatSQL/Gr...

GitHub:

https://github.com/GreatSQL/G...

Bilibili：

https://space.bilibili.com/13...

微信&QQ群：

可搜寻增加GreatSQL社区助手微信好友，发送验证信息“加群”退出GreatSQL/MGR交换微信群

QQ群：533341697

微信小助手：wanlidbc

本文由博客一文多发平台 OpenWrite 公布！