SQL InnoDB Cluster 的 MySQL Shell 与自动 failover 配置模板

innodb cluster 添加实例失败主因是group replication未启用或权限不足；自动failover不触发因节点未进入faulty状态；dba.configurelocalinstance()报错多因配置文件冲突；应用连接中断源于未部署mysql router或dns缓存未更新。

MySQL Shell 连接 InnoDB Cluster 时提示 Cluster.addInstance() 失败：权限不足或实例状态异常

常见错误是执行 cluster.addInstance('user@host:port') 后卡住、报错 Error: Group Replication is not running 或 access denied for user。根本原因不是密码错，而是目标实例没开 Group Replication，或 MySQL 用户没授全必要权限。

实操建议：

• 确认目标实例已启用 group_replication 插件：INSTALL PLUGIN group_replication SONAME 'group_replication.so';，且 group_replication_group_name 与集群一致（用 select @@group_replication_group_name; 核对）
• 创建专用用户并授最小必要权限：CREATE USER 'gradmin'@'%' IDENTIFIED BY 'pass'; GRANT BACKUP_ADMIN, GROUP_REPLICATION_ADMIN, PERSIST_RO_varIABLES_ADMIN, REPLICATION_SLAVE_ADMIN, SESSION_VARIABLES_ADMIN ON *.* TO 'gradmin'@'%';
• 确保 server_id、binlog_format=ROW、enforce_gtid_consistency=ON、gtid_mode=ON 已在 my.cnf 中配置并重启生效

自动 failover 不触发：InnoDB Cluster 的 faulty 状态没被识别

InnoDB Cluster 默认不主动踢出故障节点，除非它进入 FAULTY 状态——而这个状态依赖于组复制的内部心跳和仲裁机制。如果网络抖动但未断连、或实例卡在 RECOVERING 状态太久，Shell 可能仍显示 ONLINE，导致 failover 不启动。

实操建议：

• 检查集群视图是否同步：cluster.status() 输出里每个成员的 status 字段必须是 ONLINE；若出现 UNREACHABLE 或 MISSING，说明组内通信已断裂
• 调大超时参数防误判：在配置实例时加 --group-replication-member-expire-timeout=6000（单位毫秒），避免短暂延迟触发误剔除
• 不要依赖单点心跳：确保至少 3 个节点（奇数），否则脑裂时无法达成多数派投票，faulty 状态不会被确认

MySQL Shell 配置模板中 dba.configureLocalInstance() 报错 Unable to start Group Replication

这个函数本质是帮你自动生成并写入 my.cnf 片段，但常因路径、权限或已有配置冲突失败。最典型的是它试图覆盖 mysqld 进程正在读取的配置文件，而你没停服务，或配置项已被其他工具（如 mysqld_safe 脚本）硬编码。

实操建议：

• 先手动停掉 MySQL：sudo systemctl stop mysql，再运行 dba.configureLocalInstance()，避免配置写入后被运行中进程忽略
• 检查输出日志里实际修改了哪个文件（通常是 /etc/my.cnf 或 /etc/mysql/mysql.conf.d/mysqld.cnf），确认该路径下没有同名 [mysqld] 段重复定义 server_id 或 group_replication 相关参数
• 如果用 docker，别让 configureLocalInstance() 写宿主机配置——改用 --defaults-file 指向容器内路径，并挂载配置卷

failover 后应用连接中断：没配 mysqlrouter 或 DNS 缓存没清

Cluster 自身切换主节点很快（秒级），但应用层不感知。如果你直连某个 IP，failover 后那个 IP 变成只读，查询会报 ERROR 1290 (HY000): The MySQL server is running with the --read-only option；更隐蔽的问题是客户端 DNS 缓存没更新，还在往旧地址发请求。

实操建议：

• 必须部署 mysqlrouter 并启用 metadata-cache：mysqlrouter --bootstrap cluster_admin@primary_host:3306 --user=mysqlrouter，然后让应用连 localhost:6446（读写端口）
• 检查 mysqlrouter 日志是否定期刷新元数据：tail -f /var/log/mysqlrouter/mysqlrouter.log，正常应每 5 秒看到 Metadata cache refreshed
• Java 应用加 useSSL=false&allowPublicKeyRetrieval=true&cachePrepStmts=false&rewriteBatchedStatements=true，避免驱动层缓存连接地址

真正麻烦的不是配置项本身，而是各组件间的状态同步时机——比如 mysqlrouter 刷新元数据前，cluster.status() 已显示新主，但路由还没切过去。这种窗口期只能靠压测暴露，上线前务必模拟一次主节点 kill -9。