如何部署MySQL InnoDB Cluster？

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。

1. 所有节点必须时间同步（chronyd 或 ntpd，误差 >1s 可能导致组通信超时）
2. server_id 必须全局唯一，且不能为 0 或重复值
3. 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，该节点永远不会被选为主节点，适合只读专用节点。

1. 白名单格式支持 CIDR（如 10.0.0.0/24）或逗号分隔的 IP 列表（如 "10.0.0.11,10.0.0.12,10.0.0.13"）
2. 如果节点跨子网（如混合云场景），必须把所有参与节点的 IP 全部列进白名单，不能依赖通配符
3. 修改白名单需先 dissolve() 集群，无法热更新

添加节点失败的典型原因

cluster.addInstance() 卡住或报错 Timeout while waiting for group communication to start，90% 是底层网络或防火墙问题，而非 MySQL 配置。

必须确认以下端口在所有数据节点之间双向可达：

1. 33061：MGR 组通信端口（不是 MySQL 客户端端口）
2. 33060：X Protocol 端口（mysqlsh 连接和元数据操作依赖它）
3. 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 [email protected]:3306 --user mysqlrouter

并手动检查生成的 mysqlrouter.conf 中 [routing:primary] 和 [routing:ro] 下的 destinations 是否包含全部预期节点。

1. Router 默认不校验节点角色，只按集群当前状态路由；主节点切换后，它会在几秒内自动更新，但中间存在短暂窗口期
2. 生产环境务必配合 health_check_interval 和 max_connections 显式配置，避免连接打满或健康检查滞后
3. Router 本身无高可用，两个路由节点需由外部负载均衡（如 Keepalived + VIP）兜底，不能只靠它自己

真实部署中最容易被忽略的是 report_host 的显式设置和 ipWhitelist 的精确范围控制——它们不出现在任何“成功部署”教程的显眼位置，但一旦出错，排查路径极长，且错误信息毫无指向性。