MySQL 高可用方案--MGR 第06期：分隔

MySQL数据库联盟 2021-10-11

749

通常情况下，如果某个节点发生故障，如果多数成员将其视为可疑成员，则将该问题节点剔除。

但是，可能会出现一些极端情况，比如组中多数成员出现问题，那么组将无法继续进行工作，因为剩余节点无法确保法定成员数。

比如 5 个节点的组，有 3 个节点出现问题，则剩下的 2 个节点无法达到法定投票成员数（成员个数和法定投票成员数对应关系可见下表），也就无法判断其他 3 个服务器是否已经崩溃，所以组不能自动更新元数据。这种情况就是 MGR 的网络分隔。

组成员个数	法定投票成员数	能接受的故障成员个数
1	1	0
2	2	0
3	2	1
4	3	1
5	3	2
6	4	2
7	4	3

这里补充另外一种情况：
如果有节点主动退出组，那他们会指示组重新配置自己。这意味着其他成员可以正确地重新配置组，保持成员的一致性，并重新计算法定投票成员数。比如上面的例子中，如果 3 个节点告知组一个接一个地离开，那么组成员数将从 5 变成 2，而组成员个数为 2 的组法定投票成员数也为 2，因此确保了法定投票成员数。

下面来聊聊如果系统被分隔，导致服务器不能自动实现仲裁（也就是无法达到法定投票人数）时，我们应该做什么。

1 检测分隔

在 performance_schema 库的 replication_group_members 表中，可以看到每个成员的状态。在正常情况下，也就是未分区的时候，该表显示的信息在组中的所有服务器都是一致的，如下所示：

mysql> select * from performance_schema.replication_group_members\G
*************************** 1. row ***************************
  CHANNEL_NAME: group_replication_applier
     MEMBER_ID: 1bbcfc60-0a08-11ec-8936-fa163e9b0aed
   MEMBER_HOST: node1
   MEMBER_PORT: 3306
  MEMBER_STATE: ONLINE
   MEMBER_ROLE: PRIMARY
MEMBER_VERSION: 8.0.25
*************************** 2. row ***************************
  CHANNEL_NAME: group_replication_applier
     MEMBER_ID: 22daa10e-0a0c-11ec-899d-fa163e1c875d
   MEMBER_HOST: node2
   MEMBER_PORT: 3306
  MEMBER_STATE: ONLINE
   MEMBER_ROLE: SECONDARY
MEMBER_VERSION: 8.0.25
*************************** 3. row ***************************
  CHANNEL_NAME: group_replication_applier
     MEMBER_ID: 2bb76b01-0a0c-11ec-af8a-fa163eaadfa3
   MEMBER_HOST: node3
   MEMBER_PORT: 3306
  MEMBER_STATE: ONLINE
   MEMBER_ROLE: SECONDARY
MEMBER_VERSION: 8.0.25
3 rows in set (0.00 sec)
复制

如果网络分区了，并且无法实现仲裁，则无法访问到的成员在表中显示为 UNREACHABLE。这种情况下，需要重新配置组成员，或者停掉组中存活的成员，并判断问题节点发生了什么，然后重新启动组。

2 解决分隔

MGR 可以通过强制执行特定配置来重置组成员关系列表。比如 5 个成员的组，3 个成员出现问题，则可以强制为剩下两个成员配置一致的组成员关系。大致操作步骤如下：

首先检查剩下两个未出问题成员的组通信标识符，分别登录两个节点执行下面的语句：


mysql> SELECT @@group_replication_local_address;
复制

获取到剩下两个成员的组通信标识符之后，就可以在两个服务器中的一台上使用下面语句注入新的成员配置，从而覆盖已经丢失法定人数的现有成员配置。

注意：
在强制执行新的成员配置之前，务必确保要排除的服务器确实已经关闭，否则可能造成人为脑裂情况。

具体语句如下：

mysql> SET GLOBAL group_replication_force_members="node1:33061,node2:33061,node3:33061";
复制

执行完之后，检查两个成员的 replication_group_members 表：

mysql> SELECT MEMBER_ID,MEMBER_STATE FROM performance_schema.replication_group_members;
复制

看是否只剩下这两个成员，并且确定 MEMBER_STATE 是否都为 ONLINE。

关于 MGR 网络分隔的内容就聊到这里，MGR 系列文章持续更新中，后面会聊聊恢复、常用参数、监控等内容。

文章推荐

MySQL 高可用方案--MGR 第01期：初探

MySQL 高可用方案--MGR 第02期：部署

MySQL 高可用方案--MGR 第03期：操作

MySQL 高可用方案--MGR 第04期：原理

MySQL 高可用方案--MGR 第05期：一致

MySQL 常用高可用方案

MySQL 删库到恢复

我们创建了一个 MySQL 交流社群，围绕开发、运维、DBA、架构师和其他需要用到 MySQL 的群体，群内会分享一些读书笔记、面试技巧等，同时也用于大家交流使用 MySQL 过程中遇到的问题！

入群请加下方群秘二维码，回复 MySQL，等待群秘邀你入群。

mysql

文章转载自MySQL数据库联盟，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

MySQL 高可用方案--MGR 第06期：分隔

通常情况下，如果某个节点发生故障，如果多数成员将其视为可疑成员，则将该问题节点剔除。

1 检测分隔

2 解决分隔

评论

相关阅读