InnoDB Cluster要求至少3节点，因MGR基于Paxos需多数派投票，双节点无法形成法定人数，宕机即脑裂、不可用。
InnoDB Cluster 官方明确要求**至少三个节点**才能构成可用集群。双节点无法满足 MGR（MySQL Group Replication）的法定人数（quorum）机制，强行配置会导致脑裂、自动驱逐、不可恢复的故障状态，**不是“不推荐”，而是根本不可用**。
如果你只有两台物理/虚拟机，必须补足第三节点——哪怕是最轻量的「仲裁节点」（Arbitrator），也不能用「2 节点 + 单主从模拟」替代。
为什么双节点 InnoDB Cluster 会失败
Group Replication 基于 Paxos 协议，需要多数派（majority）投票才能确认事务、选举主节点、处理故障。2 节点场景下：
- 任意一节点宕机 → 剩余 1 节点无法形成多数（1/2 ERROR 状态，所有写入被拒绝
- 网络分区发生时 → 两边各持 1 节点，都自认是 majority，可能同时接受写入，造成数据冲突（脑裂）
-
cluster.status()永远显示"groupQuorum": false，且无法通过cluster.forceQuorumUsingPartitionOf()恢复（该命令仅适用于 ≥3 节点中部分存活的场景）
真正可行的「两机房 + 高可用」折中方案
若硬件资源受限，可采用「2 数据节点 + 1 仲裁节点」部署，仲裁节点不存数据、不参与读写，只投赞成票：
- 仲裁节点可部署在任意第三台机器（如跳板机、监控服务器），甚至用
mysqlsh启动的 sandbox 实例（dba.deploySandboxInstance(3311)）临时充当 - 在每个数据节点的
mysqld.cnf中启用仲裁支持：group_replication_arbitrator=ON（仅对仲裁节点设为ON，数据节点必须为OFF） - 初始化集群时，调用
dba.createCluster()后，用cluster.addInstance("arbitrator@10.0.0.99:3311")加入仲裁实例（注意：它不运行 mysqld，而是由 MySQL Router 或专用进程模拟） - 生产环境建议使用
mysqlrouter --bootstrap自动识别仲裁角色，而非手动 hack
server_id、group_replication_local_address 等关键参数易错点
即使补足三节点，以下配置错误仍会导致 group_replication 插件加载失败或无法加入组：
-
server_id必须全局唯一且为整数（不能是1.1或空字符串），Docker 环境尤其容易因 hostname 冲突重复 -
group_replication_local_address必须能被其他节点直接 TCP 连通（如mysql-node1:33061），不能填127.0.0.1或容器内网 IP（如172.19.0.10）除非所有节点在同一 Docker 网络且互相解析正常 -
group_replication_group_seeds必须包含所有节点的group_replication_local_address，顺序无关，但缺一不可；若用域名，所有节点的/etc/hosts必须一致且无缓存 - 防火墙必须放行
33061端口（MGR 通信端口），ufw allow 33061或iptables -I INPUT -p tcp --dport 33061 -j ACCEPT
InnoDB ReplicaSet（异步主从）并接受手动故障转移。任何绕过 quorum 的尝试，最终都会在凌晨三点以 ERROR: Group has no quorum 报警收场。 
