dba.createcluster()能跑通不等于集群真正可用，根源常在网络可达性、插件未显式加载（需plugin_load_add=group_replication.so）、server_id非全局唯一、gtid_mode和enforce_gtid_consistency未启用、binlog_format非row、group_replication_local_address填错（不能用127.0.0.1）、防火墙未放行33061端口、ntp不同步或mysqlrouter配置不当。
dba.createCluster() 能跑通，不等于集群真正可用。很多团队卡在“状态显示 ONLINE 却无法自动故障转移”，根源往往不在 MySQL 本身，而在网络可达性、插件生命周期或时钟同步这类基础项上。
group_replication 插件必须显式加载且参数匹配
MySQL 启动时不会自动加载group_replication 插件，哪怕配置了相关参数。没加载就执行 START GROUP_REPLICATION，必然报错 ERROR 3092 (HY000)。
- 每个节点的
my.cnf必须包含：plugin_load_add = 'group_replication.so' -
server_id必须全局唯一（不能全设为 1） -
gtid_mode=ON和enforce_gtid_consistency=ON缺一不可 -
binlog_format=ROW是硬性要求，MIXED或STATEMENT会导致复制中断 -
group_replication_single_primary_mode=ON（单主）或=OFF（多主）需全集群一致，混用会拒绝加入
group_replication_local_address 填错是最常见的“假通真断”原因
这个地址不是监听地址，而是其他节点用来反向连接你的地址。填127.0.0.1:33061 或 localhost:33061 看似能启动，但节点间握手永远失败。
- 正确写法是：用主机名或内网 IP，例如
mysql-node1:33061，且该主机名必须能在所有节点上ping通、telnet连通 -
group_replication_group_seeds列表里的地址格式必须与各节点的local_address完全一致（主机名对主机名，IP 对 IP） -
防火墙必须放行
33061端口（不是3306），跨云环境还要确认安全组策略
MySQL Shell 初始化必须分步执行，不能跳过 configureLocalInstance()
直接dba.createCluster() 很容易因配置缺失失败，尤其当 log_bin、server_id 等未生效时。
- 先连到每个节点执行：
dba.configureLocalInstance('root@localhost:3306')，它会自动检查并提示缺失项，还能帮你生成合规配置 - 该命令会修改
my.cnf并重启 mysqld，若失败要手动补全后再重试 - 第一个节点用
dba.createCluster('mycluster')；其余节点必须用cluster.addInstance('root@mysql-node2:3306')，不能重复create - 添加完后立即查：
cluster.status()，重点关注status字段是否全为ONLINE，以及role是否有且仅有一个PRIMARY
集群健康不等于业务可用，Router 和时间同步是隐形门槛
performance_schema.replication_group_members 显示全 ONLINE，不代表应用能正常读写。
-
mysqlrouter必须部署在独立节点（不能和 MySQL 实例共存），配置文件里routing_strategy要匹配业务读写模式（如first-available或round-robin-with-fallback） - 所有节点 NTP 必须严格同步，误差超过 500ms 就可能触发脑裂，
ntpq -p要看到reach为 377、offset在 ±10ms 内 - 如果用 Keepalived + VIP，确保
check_script检测的是SELECT @@innodb_cluster_name而非简单端口探测，否则 VIP 可能漂到已离线但进程未死的节点上
真正麻烦的从来不是命令敲不对，而是某个节点的 group_replication_local_address 写成了主机名，而另一台机器的 /etc/hosts 没配——这种问题查日志不报错，只会在故障切换时突然失效。
