接触MGR有一段时间本文来源gaodai$ma#com搞$$代**码)网@了，MySQL 8.0.23的到来，基于MySQL Group Replicaion（MGR）的高可用架构又提供了新的架构思路。
灾备机房的slave，如何更好的支持主机房的MGR？
MGR 到底可以坏几个节点？
这次我就以上2个问题，和大家简单聊下MGR的一些思想和功能。
一、MySQL Group Relication 成员数量的容错能力
上面的表格相信大家不会陌生了，我经常在面试里会问：“4个节点的MGR，最多坏几个呢？” ，多数人回答：“最多坏1个，坏2个就脑裂不能工作了。”
那我们来看看MGR的处理方式，是不是这个答案呢？
1）我们具有一个4节点MGR
埋一个问题：这个图一看就是Single模式，但箭头不是单向，是不是画错了？
2）此时，Second-04突然宕机了，那么MGR集群会成什么样子呢？
集群此时状态会变成：
- 每个节点会固定时间交换各自信息。
- 当没有收到Second-04节点信息后，其他成员会等待5秒。
- 这个期间Second-04肯定没有发出来消息，于是健康成员认为Second-04是可疑状态，标记UNREACHABLE状态。
- 然后健康成员按照参数：group_replication_member_expel_timeout，继续等待（此时Second-04依然是UNREACHABLE状态）。
- 当超过了group_replication_member_expel_timeout时间，健康成员就把Second-04节点驱逐出集群了。
那么重点来了，敲黑板
在Second-04，没有被驱逐出去时：
此时集群是（4节点-3健康-1坏）,这个期间如果继续坏1个节点，那么集群变成（4节点-2健康-2坏），集群没有满足多数原则，每个节点都无法写入了（除非人工干预，强制指定集群成员List）。
在Second-04，被驱逐出去后：
此时集群是（3节点-3健康-0坏），4节点集群退化成3节点健康集群了，这个时候，集群依然可以继续坏一个节点，变成（3节点-2健康-1坏）
所以4节点集群是否可以坏1个还是2个，具体要看集群处理过程哪个阶段哦。
PS：
我们说说刚才埋的问题：这个图一看就是Single模式，但箭头不是单向，是不是画错了？
首先Single模式，Second节点默认是不能写入的，但只是由于Second节点的super-read-only开启了。
将Second节点super-read-only = 0，Second节点可以正常写入，并可以同步其他节点（Primary和其他Second），传输还是基于Paxos协议的。
跑个火车：Second节点反向同步其他节点，是不会经过冲突检测阶段（理论效率要高于多写模式），没有验证，大家有兴趣可以研究下。
二、 Asynchronous Connection Failover
MySQL 8.0.22,推出了异步复制连接故障转移，很多朋友都发文做了介绍，这里我只简单描述下：
转载请注明原文链接：MySQL 8.0.23中复制架构从节点自动故障转移的问题
