必须先运行dba.configurelocalinstance()，因为mysql 8.0默认配置不满足group replication要求，该命令会自动启用gtid_mode=on、enforce_gtid_consistency=on、log_slave_updates，设置server_id和binlog_format=row；跳过将导致dba.createcluster()报错“instance configuration is not valid for innodb cluster usage”。
能，但必须用 MySQL Shell 8.0+ 连接本地实例后分步执行，不能跳过 dba.configureLocalInstance() 和权限校验。
为什么必须先运行 dba.configureLocalInstance()
MySQL 8.0 默认配置不满足 Group Replication 要求，dba.configureLocalInstance() 不是可选项，它会自动修改关键参数：启用 gtid_mode=ON、设置 enforce_gtid_consistency=ON、开启 log_slave_updates、生成唯一 server_id，并确保 binlog_format=ROW。跳过这步直接 dba.createCluster() 会报错：Instance configuration is not valid for InnoDB cluster usage。
- 该命令需以具有
SUPER或SYSTEM_VARIABLES_ADMIN权限的用户连接（如root@localhost） - 若实例已启用复制或存在残留 MGR 配置，它会提示冲突并建议手动清理
- 执行后会重启 mysqld（仅限 sandbox 模式；生产环境需手动重启）
dba.createCluster() 的关键参数和陷阱
创建集群时名称不能含下划线或大写字母（否则后续 cluster.status() 可能解析失败），且必须在已连接的实例上执行 —— 该实例自动成为 seed。
-
memberWeight影响故障时的主节点选举权重，默认 50，建议设为 80/50/30 避免平票 -
ipWhitelist必须显式指定，如"192.168.10.0/24"；空值或"127.0.0.1"会导致其他节点无法加入 -
memberSslMode生产环境务必设为"REQUIRED"或"VERIFY_CA"，默认AUTO在某些 OS 上会退化为未加密 - 集群名一旦设定，无法通过 AdminAPI 修改，只能解散重建
添加节点时 cluster.addInstance() 最常卡在哪
不是网络不通，而是目标实例没提前运行 dba.configureLocalInstance()，或连接 URI 中的用户名没被授予 CLUSTER_ADMIN 权限。
- URI 格式必须为
"icadmin@192.168.10.31:3306"，不能省略端口，不能用主机名（除非所有节点/etc/hosts已统一映射） - 如果报错
Access denied for user 'icadmin'@'xxx'，说明该用户缺少GROUP_REPLICATION_ADMIN或SERVICE_CONNECTION_ADMIN - 添加第三节点前，务必先确认前两个节点状态均为
ONLINE，否则新节点会卡在RECOVERING状态超时失败 - 生产环境添加节点耗时较长（尤其数据量大时），不要中断 shell 会话；可用
cluster.status({'extended': 3})查看实时同步进度
真正容易被忽略的是：集群创建后，cluster.status() 显示的 status 字段只反映 MGR 层连通性，不验证应用层写入是否真能路由成功。上线前必须用 MySQL Router 绑定 VIP 并实际执行跨节点事务测试，否则可能在故障切换时才发现 binlog purging 策略或 auto-increment offset 配置不一致。
