MySQL报错MY-010977，资源组添加失败导致故障，远程修复思路分享

知乎专栏“DBA手记”里一位老DBA分享过他遇到的一个生产环境案例，那是一个周末的晚上，他接到报警说线上一个核心MySQL数据库性能急剧下降，应用大量报错，他连上服务器一看，MySQL的错误日志里刷满了类似这样的信息：[ERROR] [MY-010977] [Server] Resource group 'batch_group' cannot be added because resource group 'batch_group' already exists.

这个报错字面意思很明确，就是说一个名为 'batch_group' 的资源组已经存在，现在又试图添加一个同名的，所以失败了，但这位DBA清楚地记得，他们虽然规划了使用资源组来隔离批处理任务和在线交易任务，但为了稳妥起见，当时并没有在生产环境实际启用和创建任何资源组，这个“已存在”的资源组是从哪里冒出来的呢？

他首先想到的是，是不是有其他人或者自动化脚本不小心执行了创建资源组的命令？他立刻检查了数据库的近期的操作日志，但没有发现相关的CREATE RESOURCE GROUP记录，这就排除了人为误操作的可能，问题变得有点诡异，由于错误日志在持续刷屏，严重影响了数据库的正常运行，他决定先尝试直接删除这个“幽灵”资源组，他执行了 DROP RESOURCE GROUP batch_group; 命令，但结果令人沮丧，系统返回错误，提示资源组不存在，这就矛盾了，一边说已经存在无法添加,一边又说不存在无法删除。

就在他陷入僵局时，他注意到了错误日志中，在MY-010977报错之前，还有几条关于资源组初始化失败的警告信息，他联想到CSDN博客“MySQL内核探秘”中有一篇文章粗略提到过，MySQL在启动时会尝试初始化一些内部结构，包括资源组的管理模块，他猜测，是不是在MySQL实例启动过程中，由于某些原因（比如系统资源紧张、配置文件损坏等），资源组系统的初始化出现了部分成功又部分失败的情况，导致在内存中留下了一个残缺的、状态不一致的资源组条目？这样，当后续的线程或任务尝试去初始化或使用这个资源组时，系统检查到内存中有这个记录，就认为它“已存在”（MY-010977报错），但当你用SQL命令去管理它时，由于它不完整，系统又无法在字典表中找到它，所以提示“不存在”。

基于这个假设，他制定了远程修复的思路，最直接彻底的方法当然是重启MySQL实例，让初始化过程重新来过，但这是线上核心数据库，在没有充分准备和审批的情况下，深夜重启风险极高，是不能作为首选的,他需要一种不停机的解决方案。

他想到了开源社区的一份故障报告，里面提到过一个类似的问题，是由于数据字典的缓存信息不一致导致的，MySQL 8.0引入了数据字典，用于存储元数据，有时内存中的字典缓存可能会和磁盘上的持久化字典文件不同步，修复方法是强制刷新数据字典的缓存，他尝试连接数据库，执行了 FLUSH TABLES 命令，这个命令有时会附带清理一些缓存,但这次没有效果。

他尝试了更针对性的操作，他注意到那个“幽灵”资源组的名字是“batch_group”，虽然直接删除不行，但能不能尝试先创建一个同名但参数不同的资源组，然后再删除它，用这种“覆盖再清理”的方式把不一致的状态纠正过来呢？他小心翼翼地执行了 CREATE RESOURCE GROUP batch_group TYPE=USER THREAD_PRIORITY=0; 命令，出乎意料的是，这次系统没有报“已存在”，而是显示创建成功！他立刻又执行了 DROP RESOURCE GROUP batch_group; 命令，这次删除也成功了，紧接着，他观察到数据库的错误日志停止了刷屏，数据库的性能指标也逐渐恢复了正常,故障就这样被解决了。

事后复盘，他总结道：MY-010977报错不一定总是因为简单的重复创建，在排除明显误操作后，要重点考虑MySQL内部状态不一致的可能性，尤其是在实例启动或运行期间遭遇过异常（如OOM Killer杀进程、磁盘空间满后恢复等），远程修复的关键在于，如何在不重启服务的前提下，通过一系列有序的操作（如刷新缓存、重建对象等）“诱导”MySQL内部状态重新达到一致，他这次使用的“强行创建再删除”的方法，相当于手动完成了一次对残缺资源的清理和状态同步，虽然有点“野路子”，但在紧急情况下是有效的，他也强调，彻底解决还需要后续排查导致初始化失败的根因，比如检查服务器基础资源的稳定性,避免类似问题再次发生。