MySQL报错MY-010887奇怪信息替换问题，远程帮忙修复故障全过程

那天下午，我正打算收拾东西下班，手机突然急促地响了起来，一看，是运维团队的小王打来的，接起电话，那头传来他焦急的声音：“哥，不好了！生产库的MySQL突然挂了，重启也起不来，错误日志里全是看不懂的乱码，我们完全没头绪，你快帮忙看看！”

我一听是生产库，睡意全无，立刻回家打开电脑，连上了远程桌面，小王已经把错误日志的截图发过来了，我一看，确实有点奇怪，MySQL的错误日志里，本该是显示具体文件路径和错误描述的地方，出现了一些像MY-010887这样的代码，夹杂着一些像是被替换了的、毫无意义的单词串，比如在应该显示文件路径的地方变成了“cannot_open_file”，在描述错误原因的地方变成了“invalid_argument”。

（来源：根据用户描述的故障场景，错误日志中出现了MY-010887等代码以及“cannot_open_file”等被替换的字符串）

这种状况我确实是第一次见，通常MySQL报错会很直接地告诉你哪里出了问题，无法打开文件/var/lib/mysql/ibdata1”或者“端口3306已被占用”，但现在这种像是模板化的错误信息，把真正的关键细节都隐藏起来了,给排查带来了巨大的困难。

我首先怀疑是不是MySQL的版本问题或者某个特定的配置导致了这种“友好”的错误显示模式，我让小王检查了my.cnf配置文件，特别是看看有没有像verbose或者log-error-verbosity这类控制日志详细程度的参数被设置成了简略模式，小王检查后回复说，配置都是默认的，之前一直很正常,最近没人动过。

（来源：排查思路始于对MySQL配置文件my.cnf的检查，重点关注了日志详细程度相关的参数如log-error-verbosity）

既然配置没问题，那问题可能出在更深的地方，我让小王别急着再次启动MySQL，而是先尝试用mysqld命令配合--verbose --help参数看看能不能正常输出帮助信息，结果命令一执行，输出的帮助信息也是同样的问题，很多关键的选项描述都被替换成了“option_description”之类的占位符。

（来源：通过执行mysqld --verbose --help命令，发现帮助信息也被异常替换,将排查方向引向MySQL二进制文件本身）

这下问题就比较明确了：不是配置或数据文件损坏，极有可能是MySQL服务器的主程序文件mysqld本身出了岔子，我脑子里闪过几个可能性：被病毒木马感染了？系统库文件损坏？或者是不小心被其他软件覆盖了？

我让小王立刻检查一下mysqld文件的完整性，首先让他用md5sum或sha256sum命令计算一下当前出问题的mysqld二进制文件的哈希值，然后去官网下载一个同版本、同操作系统的MySQL安装包，解压后对比两个mysqld文件的哈希值是否一致。

（来源：通过对比生产环境mysqld二进制文件的哈希值与官网下载的原版哈希值,来判断文件是否被篡改）

小王很快照做了，不一会儿，他惊呼道：“哥，哈希值不一样！果然被改了！” 原因找到了，就是这个mysqld文件被某种东西或某个操作给破坏了，导致其内部的字符串资源异常,所以报错信息和帮助信息都显示成了奇怪的替换文本。

接下来就是修复了，修复方案很简单，但操作需要非常谨慎，因为是在生产环境,我让小王做了以下几件事：

1. 立即备份：虽然数据库目前起不来，但还是让他把整个MySQL的数据目录（通常是/var/lib/mysql）先完整打包备份一份,以防万一。
2. 停止MySQL服务：确保MySQL进程已经完全停止。
3. 替换二进制文件：从官网下载的纯净安装包中，提取出mysqld文件，替换掉当前服务器上被损坏的那个，替换前,务必备份旧的损坏文件。
4. 调整文件权限：替换后，使用chmod和chown命令，将新的mysqld文件的权限和属主设置得和原来一模一样，通常是root:mysql和755权限。
5. 再次启动：尝试启动MySQL服务。

（来源：修复过程的关键步骤：备份数据、停止服务、用原版文件替换损坏的mysqld二进制文件、恢复权限、重启服务）

小王一步一步操作，当执行到启动命令systemctl start mysql后，我们俩都屏住呼吸盯着日志，几秒钟后，熟悉的、正常的启动信息一行行滚动出来，没有出现任何错误，小王赶紧用客户端连上去，确认数据库可读可写，所有数据和表都完好无损,故障成功修复了！

问题虽然解决了，但根源还没找到，好端端的mysqld文件怎么会坏掉呢？我让小王回忆一下最近服务器上做过什么操作，他想了半天，突然说：“啊！我想起来了！大概在出问题前一两个小时，系统自动进行过一次安全更新，好像更新了一些系统库和安全补丁，是不是那个更新过程 somehow 影响到了MySQL的文件？”

（来源：根据运维人员回忆，故障发生前服务器进行过自动安全更新,推测可能是更新过程中某些环节损坏了mysqld二进制文件）

这个可能性非常大，有些系统更新可能会替换或修改一些共用的库文件，如果在更新过程中发生意外（如磁盘空间不足、网络中断、软件包冲突等），就有可能损坏像mysqld这样依赖这些库的应用程序二进制文件，我建议他以后在部署系统自动更新策略时，可以考虑设置一个维护窗口，并在更新前后对关键服务的核心文件进行校验,或者先在测试环境验证后再应用到生产环境。

这次远程救援总算是有惊无险，那个奇怪的MY-010887错误，归根结底是MySQL的“嘴巴”（mysqld程序）本身坏了，导致它想说却说不出清楚的话，通过对比文件哈希值这个简单有效的方法，我们快速定位了问题所在，并用一个“换嘴”的操作解决了故障。