dba.createcluster() 必须在满足权限、网络、参数三前提下调用，需先用dba.checkinstanceconfiguration()逐节点验证gtid、row格式、必要权限等；ipwhitelist为强制参数，未配置将导致addinstance()超时或拒绝连接。
dba.createCluster() 是部署 MySQL InnoDB Cluster 的起点，但直接调用它大概率失败——因为前置条件没满足，不是配置问题，是权限、网络、参数三者缺一不可。
检查实例是否满足集群准入条件
必须用 dba.checkInstanceConfiguration() 逐节点验证，不能跳过。这个函数会检测：GTID 是否启用、binlog_format 是否为 ROW、enforce_gtid_consistency 是否为 ON、用户权限是否完整（尤其 BACKUP_ADMIN、CLONE_ADMIN、PERSIST_RO_VARIABLES_ADMIN 这三个 8.0 新增权限常被遗漏）。
常见错误现象：ERROR: The account 'myadmin'@'%' is missing privileges required to manage an InnoDB cluster —— 这时别急着加 GRANT，先确认该用户是否具备 WITH GRANT OPTION，否则权限无法传递给元数据 schema。
- 所有节点必须时间同步（
chronyd或ntpd，误差 >1s 可能导致组通信超时） -
server_id必须全局唯一，且不能为 0 或重复值 - MySQL 实例必须已启动，并监听在可被其他节点访问的 IP 上（不能只绑
127.0.0.1）
创建集群时指定白名单和权重
首次调用 dba.createCluster() 时，ipWhitelist 参数不是可选项，而是强制项。MGR 组通信默认拒绝非白名单 IP 的加入请求，不设白名单会导致后续 addInstance() 直接超时或拒绝连接。
示例命令：
mysql-js> dba.createCluster('prod-cluster', {
memberWeight: 80,
ipWhitelist: "10.0.0.0/24"
})
memberWeight 影响故障转移时的主节点选举优先级（范围 0–100），但仅在单主模式下生效；若设为 0，该节点永远不会被选为主节点，适合只读专用节点。
- 白名单格式支持 CIDR（如
10.0.0.0/24）或逗号分隔的 IP 列表（如"10.0.0.11,10.0.0.12,10.0.0.13"） - 如果节点跨子网（如混合云场景），必须把所有参与节点的 IP 全部列进白名单，不能依赖通配符
- 修改白名单需先
dissolve()集群，无法热更新
添加节点失败的典型原因
cluster.addInstance() 卡住或报错 Timeout while waiting for group communication to start，90% 是底层网络或防火墙问题，而非 MySQL 配置。
必须确认以下端口在所有数据节点之间双向可达：
-
33061：MGR 组通信端口（不是 MySQL 客户端端口） -
33060：X Protocol 端口（mysqlsh连接和元数据操作依赖它） -
3306：客户端连接端口（路由和健康检查需要）
不要只用 telnet 测试，用 nc -zv 10.0.0.12 33061 实测；CentOS 7 默认 firewalld 未关闭时，即使 systemctl stop firewalld，也可能残留 iptables 规则。
另一个高频坑：report_host 和 report_port 未显式设置。MGR 节点间通过这两个变量互相发现地址，若为空或为 localhost，会导致其他节点尝试连 127.0.0.1:33061 而失败。
MySQL Router 自动配置的边界
mysqlrouter --bootstrap 能自动拉取集群拓扑并生成配置，但它只读取当前在线节点的状态。如果某节点处于 MISSING 或 UNREACHABLE 状态，Router 不会为其生成路由规则，也不会报错提示——这会导致业务流量被静默丢弃。
建议每次变更集群后执行：
mysqlrouter --bootstrap admin@10.0.0.11:3306 --user mysqlrouter
并手动检查生成的 mysqlrouter.conf 中 [routing:primary] 和 [routing:ro] 下的 destinations 是否包含全部预期节点。
- Router 默认不校验节点角色，只按集群当前状态路由；主节点切换后，它会在几秒内自动更新，但中间存在短暂窗口期
- 生产环境务必配合
health_check_interval和max_connections显式配置，避免连接打满或健康检查滞后 - Router 本身无高可用，两个路由节点需由外部负载均衡（如 Keepalived + VIP）兜底，不能只靠它自己
report_host 的显式设置和 ipWhitelist 的精确范围控制——它们不出现在任何“成功部署”教程的显眼位置，但一旦出错，排查路径极长，且错误信息毫无指向性。
