MySQL MGR多数派节点宕机集群修复案例分析

来源：这里教程网时间：2026-03-01 18:35:15 作者：

1 、 MGR 介绍

MySQL Group Replication （ MGR ）组复制在 5.1.17 版本中开始引入，基于” paxos ”协议实现的数据一致性和高可用的集群方案，用于解决异步或者半同步复制可能产生的不一致性。它是 mysql 自带的插件 (group_replication.so) ，支持节点的故障自动检测、弹性扩展等功能，同时还支持单主或多主写，自动检测冲突，保证数据的最终一致性。

与 MHA 相比， MGR 通过“ paxos ”协议进行自动选举主节点，保证多数派原则集群就可以正常服务，自动切换，减少了人工介入成本；在选举前， MGR 会一直感知节点的状态，对于异常节点不会参与选举过程。

通过查询 performance_schema 下的 replication_group_members 表可以知道 MGR 集群中节点的状态，如下：

· CHANNEL_NAME : 显示的值永远为 group_replication_applier

· MEMBER_ID : 节点 serer_uuid

· MEMBER_PORT : 节点服务端口，取值为 server_port 指定的端口

· MEMBER_HOST : 如果没有配置 report_host 选项，那么取值为机器的 hostname ，可以通过 report_host 配置指定具体的 IP

对于 MGR 架构来讲，节点新增或发生故障，又该如何进行处理，参考如下：

当一个节点加入一个 MGR 组，其状态先会变成 RECOVERING ，表示当前节点正处于恢复阶段，这个阶段，节点会选择集群中一个节点 (donor 节点 ) ，利用传统的异步复制做恢复。当数据能够成功追平，节点的状态将会变成 ONLINE ，这个过程中通过其他节点也可以看到该节点的状态，不管是 RECOVERING 还是最后的 ONLINE 。

假如该节点在 RECOVERING 阶段出现了异常 ( 选 donor 进行复制失败 or 在 donor 追数据的过程中失败），那么该节点的状态将会变成 ERROR ，注意，这时候在其他节点上查询时，发现该 RECOVERING 节点已经从组里面被踢出。

另外，如果一个 ONLINE 节点失去与其他节点的通讯（可能因为节点 crash 或者网络异常），则该节点在其他节点上面查询到的状态将会是 UNREACHABLE 。如果这个 UNREACHABLE 节点在规定的超时时间内没有恢复过来，那么节点将会被踢出去。这个规定的超时时间是多少呢？下面会讲这个时间在集群失去这个节点是否可用的条件下是不一样的。

可疑的 UNREACHABLE 状态。 UNREACHABLE 节点在规定的超时时间内如果没有恢复过来，那么节点将会被踢出去。这个规定的超时时间，取决于集群失去这个节点下还是不是达到可用状态（ MGR 采用多副本，在 2N+1 个节点集群中，集群只要 N +1 个节点还存活着，数据库就能稳定的对外提供服务）。假设失去这个节点，集群仍然可用，那么这个 UNREACHABLE 的超时时间很短，几乎看不到这个状态；但是，如果失去这个节点后集群马上不可用，那么这个 UNREACHABLE 节点的超时时间，近似于无线大，将会一直处于 UNREACHABLE!