MySQL报错MY-011650，符号ER_GRP_RPL_IS_STOPPING，远程帮忙修复故障过程分享

这个故障是我在帮一个朋友处理他们公司测试环境的MySQL数据库时遇到的，当时他们正在尝试重启一个数据库集群中的节点，结果这个节点怎么也加不回集群里，应用连不上，管理页面上一直报错，错误代码就是MY-011650，信息里包含“ER_GRP_RPL_IS_STOPPING”，朋友发来截图,问我有没有碰到过。

我一开始也没头绪，就让他把完整的错误日志发给我看看，根据MySQL官方文档对错误代码的解释，这个错误的意思是“Group Replication is stopping”，也就是组复制正在停止过程中，但问题是，他们的操作是想启动节点并加入组，系统却反馈说“正在停止”，这明显是状态卡住了，停也没停彻底,起也起不来。

我让他先别乱动，然后远程连上去帮他检查，我让他执行了查看组复制状态的命令，就是那个SELECT * FROM performance_schema.replication_group_members;，结果发现，这个故障节点在别的正常节点眼里，状态显示确实是“ERROR”，但好像又残留了一些东西，这说明集群的其他成员认为这个节点已经坏了,但故障节点自身的后台进程可能还没清理干净。

我参考了网上一些有经验的DBA分享的案例，决定先在这个故障节点上，把组复制彻底停下来，我让他执行了停止组复制的命令，命令执行后好像卡住了，没有立刻返回成功，这印证了我的猜测，有某个进程或线程卡在了“停止”这个动作上。

等了大概一两分钟，我让他强行中断了那个命令，然后进行更彻底的清理，我指导他执行了另一个关键操作，重置组复制的所有配置，这个操作（根据MySQL官方手册的描述）会清除掉组复制的内部状态和恢复用的通道，执行完之后，整个组复制在这个节点上就等于被“归零”了。

清理完成后，我让他重启了MySQL数据库服务，服务启动后，先不急着加组，而是检查一下MySQL实例本身是否完全正常，确认基础服务没问题后，我们才重新开始配置组复制参数，就像第一次设置这个节点一样，设置好组复制的启动选项,然后执行启动组复制的命令。

这一次，启动命令顺利执行了，我们再次查看组复制成员状态，在等待了几十秒后，这个节点的状态终于从“RECOVERING”（恢复中）慢慢变成了“ONLINE”（在线），朋友那边在管理平台上也看到节点恢复了绿色,应用测试连接也成功了。

整个处理过程，核心原因就是组复制组件在停止时进入了某种“死锁”或异常状态，导致其状态机混乱，既不是运行也不是停止，解决方法就是通过重置操作（根据社区故障处理经验），强行清理掉这些残留的内部状态，然后从头重新加入集群，这就像一台机器卡死了，关机关不掉，那就只能拔电源，然后重启，事后我提醒他，以后重启这类集群节点，最好先通过管理命令正常将其从集群中移除，再进行操作,避免直接重启服务导致状态不一致。