START GROUP_REPLICATION成功不等于GR就绪，常见卡在分布式恢复阶段；必须选GTID最新、数据最全的节点为唯一引导节点，严格配置local_address与group_seeds，确保网络互通、server_id唯一、凭据正确。
START GROUP_REPLICATION 能成功执行，不代表 GR 已真正就绪；常见失败是卡在分布式恢复阶段，根本原因是初始成员没选对、网络配置没对齐、或凭据缺失。
怎么选第一个启动的节点（初始成员）
必须且只能有一个节点先以引导模式启动，否则会脑裂或拒绝加入。这个节点不是“随便挑一个”，而是要满足：
• 数据最全、GTID 位点最新（不能有落后或空数据）
• group_replication_bootstrap_group=ON 只能在它上面临时设为 ON，其他节点必须为 OFF
• 启动前确保该节点已停掉所有复制通道：STOP SLAVE FOR CHANNEL 'group_replication_recovery';
• 引导完成后立刻执行：SET GLOBAL group_replication_bootstrap_group=OFF;，否则下次重启会重复引导出错
local_address 和 group_seeds 必须严格匹配真实网络
这两个参数不是“写个 IP 就行”，它们直接决定节点间能否建立 XCom 连接：
• group_replication_local_address 必须是该节点**能被其他节点直连的 IP + MGR 专用端口**（比如 10.9.95.110:13306），不能写 127.0.0.1 或容器内网 IP
• group_replication_group_seeds 是“种子列表”，必须包含所有节点的 local_address，顺序无关，但缺一不可
• 所有节点的防火墙必须放行 13306（或你配的 MGR 端口），MySQL 的 3306 端口不参与组通信
• 建议用 telnet 10.9.78.64 13306 在每个节点上实测连通性，别只信 ping
MySQL 8.0.21+ 启动时传凭据更安全
旧方式（CHANGE MASTER TO ... FOR CHANNEL 'group_replication_recovery'）把密码存进系统表，重启后还在；新方式把凭据控制在内存里，更可控：
• 先创建复制用户：CREATE USER 'repl'@'%' IDENTIFIED WITH 'mysql_native_password' BY 'xxx'; GRANT REPLICATION SLAVE ON *.* TO 'repl'@'%';
• 启动时显式传参：START GROUP_REPLICATION USER='repl', PASSWORD='xxx';
• 注意：PASSWORD 不能为空或 NULL，且该凭据只用于分布式恢复阶段，不会持久化
• 如果用了这个语法，就不用再配 group_replication_recovery 通道的凭据了，否则会冲突
为什么 START GROUP_REPLICATION 后 SHOW PROCESSLIST 看不到 GR 线程
这不是成功信号，反而是典型卡点：
• 检查 SELECT * FROM performance_schema.replication_group_members; —— 如果状态是 OFFLINE 或 RECOVERING 超过 2 分钟，基本就是恢复失败
• 查错误日志关键词：Plugin group_replication reported: 'This member has more executed transactions than those present in the group.' 表示该节点 GTID 领先太多，不能当新成员加入
• 更隐蔽的问题：所有节点的 server_id 必须唯一，且不能为 0 或重复值，否则认证直接跳过，日志里只报 “ignored” 不提示原因
真正麻烦的从来不是敲命令，而是每个节点的 local_address 是否可路由、每个 server_id 是否真唯一、以及那个引导节点的数据是否干净——这些细节不验，START GROUP_REPLICATION 就只是个假动作。
