MySQL 8.0+集群必须启用group_replication插件并正确配置server_id、GTID模式及local_address等参数，否则启动失败；初始化需单节点WITH INITIAL=ON，网络可达性与插件生命周期管理是关键。
MySQL 8.0+ 必须启用 group_replication 插件才能启动集群节点
不装插件、不加载配置就执行 START GROUP_REPLICATION，会直接报错 ERROR 3092 (HY000): The server is not configured properly to be an active member of the group。
实操建议：
- 先确认 MySQL 版本是
8.0.13+（低版本不支持单主自动切换） - 在每个节点的
my.cnf中显式启用插件：plugin_load_add = 'group_replication.so' - 必须设置
server_id、gtid_mode=ON、enforce_gtid_consistency=ON，缺一不可 - 首次启动时，仅一个节点用
START GROUP_REPLICATION WITH INITIAL=ON；其余节点用普通START GROUP_REPLICATION
集群初始化失败常见于 group_replication_local_address 配置错误
这个地址不是“本机监听 IP”，而是其他节点用来反向连接你的地址 —— 如果填成 127.0.0.1 或 localhost，集群永远无法握手成功。
实操建议：
- 检查每台机器的
group_replication_local_address是否指向可被其他节点直连的 IP（比如内网192.168.10.11:33061） - 确认防火墙放行对应端口（默认
33061，不是 MySQL 主端口） - 用
telnet 192.168.10.12 33061从节点 A 测试能否连通节点 B 的本地地址 - 如果跨云厂商或 NAT 环境，
group_replication_local_address和group_replication_group_seeds必须使用一致的可达地址格式
mysqlsh 创建集群时卡在 “Waiting for the cluster to become online…”
这通常不是网络问题，而是某个节点的 group_replication_start_on_boot=OFF 且没手动启动，或者该节点上存在未提交的事务/DDL 锁。
实操建议：
- 进 MySQL 执行
SELECT * FROM performance_schema.replication_group_members;，看状态是否全是ONLINE - 若出现
RECOVERING，说明该节点正在拉取 binlog，等几分钟再查；若长期卡住，检查磁盘空间和relay_log路径权限 - 用
mysqlsh --uri root@host:port连入后，运行cluster.status()查具体节点异常原因，比日志更直观 - 不要在已有数据的实例上直接
cluster.addInstance()，除非已用mysqldump --set-gtid-purged=OFF清空 GTID 位点
集群脑裂后手动恢复必须先停掉所有节点的 group_replication 插件
一旦发生网络分区导致多个 PRIMARY，不能只靠 STOP GROUP_REPLICATION 就重搭 —— 残留的组视图元数据会让新加入节点拒绝同步。
实操建议：
- 逐个执行
STOP GROUP_REPLICATION后，再执行UNINSTALL PLUGIN group_replication - 清空
performance_schema下相关表（如replication_group_members不会自动清，但重启 mysqld 后会重置） - 重启 MySQL 实例，重新加载插件，再按初始流程重建集群
- 生产环境务必配好
group_replication_member_expel_timeout（默认 0，即不自动驱逐），避免临时抖动误判离线
部署真正跑起来不难，难的是每个节点的网络可达性、GTID 一致性、插件生命周期管理这三块细节。漏掉任意一个，cluster.status() 就永远显示不全。
