MGR集群不是“更好用的主从”，而是基于Paxos协议、多数派确认和组共识的全新协作逻辑，实现秒级自动故障切换、强一致性保障与动态节点管理。
MGR集群在MySQL 8.0中不是“更好用的主从”，而是彻底换了一套协作逻辑——它用Paxos协议替代了binlog拉取，用多数派确认替代了单点写入，故障恢复不再依赖DBA半夜爬起来执行STOP SLAVE。
自动故障切换：不需要人工干预的秒级RTO
传统主从复制下，主库宕机后必须人工介入：确认从库延迟、挑选最可靠节点、执行RESET SLAVE ALL、修改VIP或DNS、通知应用层。整个过程通常耗时数分钟甚至更久。
MGR单主模式下，一旦检测到主节点失联（默认超时group_replication_member_expel_timeout），剩余节点会基于Paxos自动发起选主流程，新主在几秒内完成状态切换并接受写请求。
- 前提是集群至少有3个节点（奇数），避免脑裂；2节点集群无法仲裁，会整体不可写
- 选主不看延迟或负载，只看节点存活状态和组视图一致性；
group_replication_single_primary_mode=ON必须开启 - 应用连接若直连数据库，需配合
MySQL Router自动重路由；否则仍会因连接旧IP失败
强一致性保障：事务提交即多数节点持久化
传统异步复制中，COMMIT返回成功 ≠ 数据已同步；半同步也只是保证“至少一个从库收到并刷盘”，但不保证已执行。MGR则要求事务必须被集群中多数节点（quorum）接收、验证、写入relay log并准备apply，才允许提交。
- 这意味着：只要集群未发生网络分区，任何已提交事务绝不会丢失
- 但代价是写性能下降——尤其跨机房部署时，Paxos消息往返延迟直接拖慢
INSERT/UPDATE - 一致性级别由
group_replication_consistency控制，默认EVENTUAL；设为BEFORE_ON_PRIMARY_FAILOVER可避免切换瞬间读到旧数据
动态节点管理：加减节点无需停服
传统主从添加新从库，需先备份+恢复+配置复制位点，过程中主库持续写入，容易因位点漂移导致同步失败；删除节点更要手动清理复制账户和监控项。
MGR通过START GROUP_REPLICATION即可让新节点加入，它会自动从集群中拉取缺失的GTID事务集，并追赶至最新状态。
- 节点加入前必须确保
server_id唯一、gtid_mode=ON、enforce_gtid_consistency=ON - 退出节点执行
STOP GROUP_REPLICATION后，其他节点会在几秒内更新组视图；但该节点本地数据不会自动清理，需DBA手动处理 - 不支持在线降级单节点为从库——MGR节点角色由组共识决定，个体无权声明自己是“从”
运维复杂度的真实代价：配置错一个参数就卡住启动
MGR不是“开箱即用”的高可用方案。它把原本分散在外部工具（如MHA、Keepalived）里的逻辑，全部收编进MySQL内核，但这也意味着所有问题都得在MySQL层面排查。
- 常见卡点：
group_replication_local_address填错（必须是其他节点能直连的IP+端口）、group_replication_group_seeds漏写某节点、防火墙未放开33061端口（XCom通信端口） - 错误日志里出现
Plugin 'group_replication' is not active，往往是因为loose-group_replication_start_on_boot=OFF且没手动执行START GROUP_REPLICATION - 集群启动顺序必须严格：先启一个节点（作为种子），再依次加入其余节点；同时启动多个节点大概率触发选举冲突
真正难的从来不是部署，而是理解“为什么这个事务没提交”“为什么节点被踢出组”“为什么Router始终连不上主”。这些都需要盯着performance_schema.replication_group_members和error log逐行比对，而不是靠重启解决。
