MySQL报错MY-013140，ER_ERROR_INFO_FROM_DA导致故障，远程帮忙修复方案分享

MySQL报错MY-013140，ER_ERROR_INFO_FROM_DA导致故障，远程帮忙修复方案分享

（引用来源：主要基于Percona官方博客关于MySQL 8.0组件错误处理的讨论、MySQL官方文档关于“诊断区域”的说明，以及一些实际运维案例的经验总结）

最近在处理一个客户的数据库紧急故障时,遇到了一个比较棘手的错误，错误代码是MY-013140，对应的错误信息是ER_ERROR_INFO_FROM_DA，这个错误本身不像常见的“表不存在”或者“连接超时”那样直观，它更像是一个“二级错误”或者“错误包装器”，意思是“从诊断区域获取的错误信息”，就是MySQL内部某个地方真的出问题了，但最终抛给我们的提示是这个笼统的MY-013140，它把真正的根本原因给“藏”起来了，这给远程快速定位问题带来了很大挑战，下面我把这次排查和修复的过程分享一下。

故障现象描述

客户报告说他们的应用程序突然无法连接数据库,或者执行某些特定SQL语句时直接中断，并返回错误，我们通过远程连接到数据库服务器，查看MySQL的错误日志（通常是以.err结尾的文件），发现了类似如下的记录：

[ERROR] [MY-013140] [Server] Error info from DA: ...

日志中“...”的部分可能是一些更具体的描述，但在我们的案例中，它有时候信息比较模糊，有时候甚至没有提供足够清晰的线索，应用程序端收到的错误信息也同样指向MY-013140，这种情况说明，问题出在MySQL服务器内部，但我们需要找到触发这个错误的源头。

错误原因深度分析（为什么这么难搞）

（引用来源：MySQL官方手册对“诊断区域”的解释）MySQL有一个内部机制叫做“诊断区域”（Diagnostic Area, DA），它可以被理解成一个临时的错误信息黑板，当执行SQL语句时，如果发生错误，详细的错误信息（比如错误代码、错误消息、SQL状态等）会先被写入这个“诊断区域”，系统或客户端再从这个区域读取信息并展示给我们看。

ER_ERROR_INFO_FROM_DA这个错误,通常意味着在处理某个操作的过程中，确实有一个“主错误”发生了，并且被记录到了诊断区域，在后续的某个环节（比如记录日志、或者准备将错误返回给客户端时），程序试图从诊断区域获取这个“主错误”的详细信息时，自身又发生了问题，或者诊断区域的状态出现了某种不一致，结果，MySQL无法正确报告那个“主错误”，只能抛出一个更上层的、笼统的MY-013140错误，告诉我们：“我本来想告诉你出了什么错，但我连告诉你错在哪里这个动作本身都出错了！”

MY-013140本身不是根源，它只是一个信号，提示我们底层有更严重的问题需要挖掘，可能的原因范围很广，包括但不限于：

1. 内存损坏或不足：在分配内存存储错误信息时失败。
2. 插件或组件故障：某个已安装的MySQL插件（如认证插件、审计插件）内部出错，并且在报告错误时行为异常。
3. 内部表或系统表损坏：尤其是与数据字典相关的表（MySQL 8.0引入了新的数据字典），在访问这些表获取错误上下文时发生故障。
4. 特定SQL语句的解析或执行bug：某些复杂的SQL语句可能触发了MySQL内部的罕见代码路径，导致错误处理逻辑出现漏洞。
5. 版本特定的缺陷：特定版本的MySQL可能存在与错误处理相关的已知bug。

远程排查与修复步骤

由于是远程协助,我们无法直接接触服务器硬件，只能通过日志和命令来诊断，我们采取了以下步骤：

1. 收集尽可能多的日志信息：

   • 首要任务：详细错误日志，我们让客户提供完整的MySQL错误日志文件，而不仅仅是报错的那几行，我们重点关注MY-013140错误出现之前，看看有没有任何警告（Warnings）或其他轻微的错误（Errors）信息，真正的罪魁祸首就藏在前面。
   • 开启通用查询日志：如果错误是执行特定SQL触发的，我们会在业务低峰期临时开启通用查询日志，然后重现问题，这样就能精准定位到是哪一条SQL语句导致了故障。（注意：此操作会记录所有查询，对性能有影响，且可能包含敏感信息，用完务必关闭）。
   • 检查系统日志：我们还查看了操作系统的系统日志（如/var/log/messages或journalctl），排查是否有内存不足（OOM Killer）、磁盘满、或硬件故障等系统级问题，这些问题也可能间接导致MySQL内部状态错乱。

2. 分析并尝试隔离问题：

   • 比对时间点：将应用程序报错的时间点与MySQL错误日志、系统日志的时间点进行精确比对，寻找相关性。
   • 简化重现步骤：如果可能，让客户在MySQL命令行客户端中直接执行那条疑似有问题的SQL语句，观察是否稳定重现，如果能稳定重现，就大大缩小了范围。
   • 安全模式测试：我们尝试让客户以--skip-grant-tables和--skip-networking参数安全启动MySQL（这会跳过权限验证和网络连接，仅限本地维护），如果这样启动后，手动执行SQL不再报错，可能问题与权限管理或网络连接插件有关。

3. 实施修复方案： 经过上述排查，在我们的案例中，最终将问题根源锁定为MySQL 8.0某个小版本的一个已知bug，该bug在处理特定类型的存储过程调用时，会导致数据字典访问异常，进而触发MY-013140错误。

   • 我们的解决方案： a. 短期应急：我们指导客户暂时绕开引发问题的那个存储过程调用，改为多个简单的SQL语句在应用层实现相同逻辑，先恢复业务。 b. 根本解决：查阅MySQL的官方bug数据库，确认了这是一个已报告的bug，并且在更新的版本中得到了修复，我们为客户制定了详细的升级计划，在合适的停机窗口内，将MySQL升级到修复了该bug的稳定版本。

   • 其他可能的修复方向（如果原因不同）：

     • 如果怀疑内存问题：建议增加系统内存，或调整MySQL的innodb_buffer_pool_size等内存相关参数，避免过度使用。
     • 如果怀疑插件问题：尝试禁用非核心的插件（通过修改my.cnf文件），逐一排查。
     • 如果怀疑表损坏：对相关的数据库表执行CHECK TABLE和REPAIR TABLE操作（对于InnoDB表，通常REPAIR TABLE无效，可能需要从备份恢复或使用innodb_force_recovery模式导出数据）。
     • 重启大法：在万不得已且业务允许的情况下，重启MySQL服务有时能清除异常的临时状态，但这只是临时措施，可能复发。

总结与建议

处理MY-013140这类错误的关键在于，不要被它表面的错误信息所迷惑，它是一个“引子”，提醒我们需要深入挖掘底层原因，远程修复这类问题，极度依赖完整、清晰的日志信息，作为一名DBA或运维人员，养成良好的日志分析习惯至关重要，保持MySQL版本处于稳定 release，并关注官方发布的bug修复信息，可以在很大程度上预防此类深层错误的发生。