必须先运行dba.configurelocalinstance(),因其强制修正mysql 8.0默认配置:启用gtid_mode=on、enforce_gtid_consistency=on、log_slave_updates=on,设binlog_format=row和唯一server_id,否则dba.createcluster()必报“instance configuration is not valid”。

不能跳过 dba.configureLocalInstance(),否则 dba.createCluster() 必定失败。 MySQL 8.0 默认配置完全不满足 Group Replication 要求,Shell 不会自动修正——它只校验、报错、退出。
为什么必须先运行 dba.configureLocalInstance()
该命令不是“可选优化”,而是强制前置步骤。它会实际修改实例的运行时参数并写入配置文件(如 my.cnf),包括:
启用 gtid_mode=ON 和 enforce_gtid_consistency=ON;
设置 binlog_format=ROW 和 log_slave_updates=ON;
生成唯一 server_id(若未设置);
禁用 disabled_storage_engines 中的 MyISAM。
常见错误现象:dba.createCluster() 直接报错 "Instance configuration is not valid for InnoDB cluster usage",99% 是因为没跑这步。
执行要点:
- 必须用具有
SUPER或SYSTEM_VARIABLES_ADMIN权限的用户连接(如root@localhost) - 若实例已启用复制或残留 MGR 配置,会提示冲突,需手动清理
SELECT * FROM performance_schema.replication_group_members;等状态 - 在 sandbox 模式下会自动重启 mysqld;生产环境需你手动重启服务使配置生效
dba.checkInstanceConfiguration() 的真实用途
它不是“一键修复工具”,而是一个诊断命令:告诉你缺什么权限、哪个参数没开、哪项配置值不对。返回 OK 才代表能进下一步。
典型失败原因:
-
Access denied:连接用户缺少BACKUP_ADMIN、CLONE_ADMIN、GROUP_REPLICATION_ADMIN等至少 10 项权限 -
log_bin is OFF或binlog_format != ROW:说明dba.configureLocalInstance()没生效或被覆盖 -
server_id is 0 or duplicated:配置文件里写了server_id=0,或多个节点用了相同值
建议每次加新节点前都跑一次,别只信“上次配过”。
cluster.addInstance() 卡住的三个真实原因
不是网络不通,也不是磁盘慢,而是以下任一条件不满足就会卡在 RECOVERING 或直接超时:
- 目标实例没运行过
dba.configureLocalInstance()—— 即使主节点 OK,从节点也必须单独配 - URI 中的用户(如
icadmin@192.168.10.31:3306)没被授予CLUSTER_ADMIN角色(MySQL 8.0.19+)或等效权限组合 - 集群已有两个节点,但状态不是全
ONLINE:第三个节点加入前,必须确认前两个都已稳定在线,否则新节点无法完成组通信握手
注意 URI 格式:
端口不能省略(:3306 必须显式写出);
推荐用 IP,不用主机名(除非所有节点 /etc/hosts 已统一映射且 DNS 解析无延迟);
用户名必须在所有节点上存在、密码一致、权限完整。
集群名和 ipWhitelist 是上线前最容易翻车的配置
dba.createCluster("mycluster") 中的名称看似随意,实则限制严格:
不能含下划线(_)、大写字母、点号(.)或特殊字符;
一旦创建,无法通过 AdminAPI 修改,只能解散重建 —— 别用 prod-cluster-v2 这类名字。
ipWhitelist 更关键:
默认值为空或 "127.0.0.1" 会导致其他节点根本连不上 seed 实例;
必须显式设为网段,如 "192.168.10.0/24" 或具体 IP 列表 "192.168.10.31,192.168.10.32";
生产环境务必设 memberSslMode="REQUIRED",否则组内通信可能降级为明文。
真正复杂的是权限与配置的耦合性:一个节点上 dba.configureLocalInstance() 成功,不代表它有足够权限执行 addInstance();checkInstanceConfiguration() 通过,也不代表 cluster.status() 一定能显示 ONLINE。每一步都依赖前一步的精确落地,漏掉任意一个细节,整个集群就停在“几乎成功”的位置。











