innodb cluster是mysql官方唯一推荐的高可用方案，需用mysql shell基于group replication创建单主多从集群。必须提前配置gtid、row格式二进制日志、唯一server_id等参数，再执行dba.createcluster()和addinstance()，最后通过cluster.status()验证状态。
MySQL Shell 本身不直接搭建传统主从集群，它只管理基于 Group Replication 的 InnoDB Cluster（即 MGR 集群）。如果你想要“快速搭建高可用主从集群”，实际能走通的路径只有一条：用 MySQL Shell 创建 InnoDB Cluster，它底层是单主模式的组复制，对外表现就是一主多从、自动故障转移——这才是 MySQL 官方当前唯一推荐的“开箱即用”高可用方案。
dba.createCluster() 前必须满足的配置条件
MySQL Shell 不会帮你改配置文件，所有节点必须提前配好，否则 createCluster() 会直接报错退出：
- 所有实例启用
gtid_mode=ON和enforce_gtid_consistency=ON - 必须开启
log_bin，且binlog_format=ROW -
log_slave_updates=ON（MGR 要求所有节点都记录 relay log） -
server_id全局唯一，不能为 0 或重复 - 关闭
disabled_storage_engines中的MyISAM（MGR 强制要求事务引擎） - 网络互通：各节点能通过 host 名或 IP 直连彼此的 MySQL 端口（3306），且防火墙放行
常见错误现象：createCluster() 卡在 “Waiting for the cluster to become online…” 或报错 Group replication is not active，基本都是上述某项没生效。建议连接每个实例后执行：
SELECT @@gtid_mode, @@log_bin, @@binlog_format;确认返回值全为
ON/ROW。
cluster.addInstance() 时容易忽略的权限与网络细节
添加节点不是简单输个地址就行，addInstance() 实际会做三件事：建立复制通道、校验数据一致性、加入组通信。失败往往卡在前两步：
-
被添加的实例必须已创建
repl用户，并赋予权限：CREATE USER 'repl'@'%' IDENTIFIED BY 'xxx'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
注意：不是root，也不是任意用户；addInstance('repl@host:3306')中的用户名必须匹配 实例间需能双向访问：不只是 Manager 节点能连目标实例，目标实例也得能反向连回 Manager 节点（MGR 组通信依赖
loose-group_replication_local_address，该地址必须可被其他节点直连）如果用 Docker，别只映射 3306 端口，MGR 默认用
33061做组通信端口（可通过loose-group_replication_local_address改），该端口也要暴露并互通
MySQL Router 启动后读写流量不自动分离？
MySQL Router 默认只提供一个 read-write 端口（6446）和一个 read-only 端口（6447），但它不会“智能判断语句类型”来路由——它只按角色转发：
- 连
6446的请求，一律发给当前 primary 节点（即写节点） - 连
6447的请求，轮询发给所有 secondary 节点（即只读节点）
所以应用层必须自己决定连哪个端口。如果所有请求都连 6446，那就没有读写分离；如果想自动分离，得配合应用框架（如 Spring 的 @ReadOnly 注解）或中间件（如 ProxySQL）做语句识别。
另外注意：MySQL Router 的元数据缓存默认 5 秒刷新一次，主节点切换后，最长可能有 5 秒内旧客户端还在往已下线的节点发请求——这不是 bug，是设计权衡。生产环境建议在应用侧加连接重试逻辑。
InnoDB Cluster 看似一键创建，但真正稳定运行的关键不在 createCluster() 那一行命令，而在每个实例的 my.cnf 是否干净、网络是否对称、用户权限是否最小化。最容易被跳过的其实是日志校验：集群初始化后，务必执行 cluster.status()，重点看 "status": "ONLINE" 和 "role": "PRIMARY" 是否准确，而不是只盯着有没有报错。
