节点卡在recovering需先查日志、比对gtid，若数据落后则清空目录并用克隆插件同步；手动同步须严格对齐gtid与binlog起点，严禁直接start group_replication。
故障节点不能直接 START GROUP_REPLICATION 就完事——它大概率会卡在 RECOVERING 状态，甚至报错退出。恢复的关键在于：先确认数据是否一致，再决定是清空重同步，还是仅重连。
节点状态卡在 RECOVERING 怎么办
这是最常见的现象，说明该节点已尝试加入但无法完成分布式恢复（distributed recovery）。根本原因通常是 GTID 不连续、binlog 缺失，或 donor 节点拒绝提供状态传输。
- 先查日志：
tail -n 50 /var/log/mysql/error.log，重点找ERROR或WARNING行，常见关键词有GTID_PURGED、donor、cloning、applier thread stopped - 检查当前节点的 GTID 执行集：
SELECT @@global.gtid_executed;，和在线节点比对（用SELECT * FROM performance_schema.replication_group_members WHERE MEMBER_STATE = 'ONLINE';找出可用 donor） - 若该节点 GTID 明显落后，且 binlog 已被 purge，就别硬等恢复——必须清空数据目录再拉取快照
清空后用克隆插件重同步（推荐 MySQL 8.0.17+）
克隆插件比传统物理拷贝更安全，能自动处理 GTID、binlog 位点、系统表一致性，且无需停 donor 节点。
- 确保 donor 和 joiner 都启用
clone_plugin：INSTALL PLUGIN clone SONAME 'mysql_clone.so'; - 在故障节点上执行：
CLONE INSTANCE FROM 'repl'@'donor-host' IDENTIFIED BY 'password';（注意：账号需有BACKUP_ADMIN权限） - 克隆完成后，MySQL 会自动重启实例并初始化组复制状态；此时再执行
START GROUP_REPLICATION; - 验证：
SELECT MEMBER_HOST, MEMBER_PORT, MEMBER_STATE FROM performance_schema.replication_group_members;—— 状态应为ONLINE
手动物理同步时容易踩的坑
不用克隆插件时，得靠 xtrabackup 或 mysqldump 拉数据，但极易出错。
- 千万别只
rm -rf /var/lib/mysql/*后直接启动——ibdata1、auto.cnf、server-uuid这些文件必须保留或按 donor 节点重建，否则group_replication会拒绝识别该成员 - 用
xtrabackup时，务必加--apply-log --export并确认backup_gtid_executed文件存在；恢复后要执行SET GLOBAL gtid_purged = '...';（值来自备份元数据） - 如果 donor 是 secondary 节点，而你误把它设为
group_replication_bootstrap_group=ON，会导致脑裂——永远只在 primary 节点上执行 bootstrap
为什么 STOP/START GROUP_REPLICATION 常常没用
单纯执行 STOP GROUP_REPLICATION; START GROUP_REPLICATION; 只适用于网络闪断导致的临时掉线（且数据完全一致）。一旦节点本地事务状态与组内不匹配，这个操作只是重试失败路径。
- 如果错误日志里反复出现
Member was expelled from the group，说明该节点已被踢出视图（view），必须先清空状态才能重新加入 -
RESET MASTER;会清空本地 GTID，但不会同步组内状态——除非你明确知道主节点的gtid_executed并手动设置SET GLOBAL gtid_purged = '...';，否则必然失败 - 所有恢复操作前，必须确认集群仍有多数节点在线（至少 ≥3 节点中 ≥2 个 ONLINE），否则组无法达成共识，任何
START都会超时
最常被忽略的一点：恢复不是“让节点上线”，而是“让它跟上组的状态”。哪怕只差一个事务，RECOVERING 就不会结束。克隆插件能绕过这个问题，手动同步则必须严格对齐 GTID 和二进制日志起点。
