1 、 MySQL MGR 原理简介

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

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

2 、 MGR 宕机修复介绍

针对极端情况， MGR集群无法使用，下文将进行逐一介绍如何修复。

首先明确如何确定 MGR集群个节点状态是否正常，集群是否可用。

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

q  CHANNEL_NAME   : 显示的值永远为group_replication_applier

q  MEMBER_ID   : 节点serer_uuid

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

q  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!