MySQL报错ER_DES_FILE_WRONG_KEY导致故障，远程帮忙修复思路分享

前段时间,我在一个技术社区（比如CSDN或者知乎上，具体哪个帖子记不清了，但问题我记得很清楚）看到一个朋友的求助，他的MySQL数据库突然启动不了了，日志里疯狂报一个错，错误代码是ER_DES_FILE_WRONG_KEY，这个朋友急得不行，因为网站和应用都挂了，直接影响业务。

我当时正好有空,就远程帮他看了一下，最后把问题解决了，我把整个排查和修复的思路记了下来，今天分享给大家，万一以后谁遇到类似的情况，可以有个参考。

第一步：先看懂错误信息在说什么

遇到报错,千万别慌，第一步就是要把错误信息翻译成自己能懂的话，ER_DES_FILE_WRONG_KEY 这个错误代码，直接翻译过来大概是“DES文件密钥错误”，DES是一种老的加密算法，这个错误基本上是在告诉我们：MySQL在尝试读取某个文件时，用来解密的密钥不对，导致文件打不开。

下一个问题自然就是：什么文件会被加密，而且对启动这么关键？

第二步：锁定问题文件

MySQL启动过程中,有哪些核心文件是必须读的呢？最常见的就是数据目录下的那些文件，比如表空间文件（.ibd）、系统表空间（ibdata1）、日志文件（ib_logfile*）等等，但错误信息里提到了“DES文件”，这让我联想到MySQL的表加密功能。

从MySQL 5.7开始，支持了对单个表或整个表空间进行加密，加密后的表，在磁盘上存储是乱码，需要正确的密钥才能解密和读取，ER_DES_FILE_WRONG_KEY 很大概率是出现在表加密这个环节。

当时,我让那个朋友检查MySQL的错误日志文件（通常叫hostname.err），在错误日志里，除了这个错误代码，往往还会有更详细的上下文，果然，在错误信息附近，我们看到了类似“Failed to decrypt table 'database_name/table_name'”这样的字眼，这下就明确了：是有一张名为 table_name 的表，因为加密密钥问题，导致MySQL在启动时无法加载它，进而整个数据库启动失败。

第三步：分析密钥错误的原因

知道了是某张表的加密密钥不对,接下来就要想，为什么密钥会不对？可能的原因有几个：

1. 密钥环（Keyring）问题：MySQL的加解密功能依赖于一个叫“密钥环”的组件来管理和存储密钥，这个密钥环可以是一个文件（比如keyring_file），也可以是一个插件（比如Vault），最常见的情况是，服务器迁移、备份恢复或者配置文件修改后，MySQL找不到之前用的那个密钥环文件了，或者密钥环文件损坏了。
2. 密钥环配置错误：可能是MySQL的配置文件（my.cnf或my.ini）中，关于密钥环的配置参数被修改了，keyring_file_data 的路径指错了地方。
3. 备份恢复问题：如果数据库是从另一台服务器恢复过来的，而恢复时没有同时把原服务器的密钥环文件也拷贝过来，那就会出现在新服务器上无法解密旧数据的情况。

根据那个朋友的描述,他前一天晚上好像做过一次服务器维护，动过配置文件，原因大概率是第一种或第二种。

第四步：着手修复

修复的思路核心就是：让MySQL能重新找到并使用正确的密钥，我们当时是这么做的：

1. “跳过”问题表，先让MySQL启动起来：这是最关键的一步，因为MySQL不启动，很多操作都没法做，我们修改了MySQL的启动配置，在配置文件里加了一行：innodb_force_recovery = 6，这个参数的意思是让InnoDB存储引擎以最高级别的强制恢复模式启动，它会尽量跳过各种错误，包括读取出错的数据页，这样做的目的是让MySQL服务先跑起来，我们才能进去操作。

   • 重要提醒：innodb_force_recovery = 6 是最后的手段，启动后只能进行 SELECT 查询，绝对不能做 INSERT, UPDATE, DELETE 等写操作，否则可能导致数据彻底损坏，我们的目的只是读数据出来备份。

2. 启动后，验证和修复密钥环配置：MySQL以恢复模式启动后，我们首先检查了密钥环的配置，通过执行 SELECT * FROM information_schema.plugins WHERE plugin_name LIKE '%keyring%'; 确认密钥环插件是加载的，核对配置文件中的 keyring_file_data 路径，发现他前一天修改配置时，不小心把这个路径写错了一个字母，我们把它修正为正确的路径，指向了那个存有原始密钥的keyring文件。

   

3. 恢复正常启动：修正了密钥环路径后，我们关闭了MySQL实例。必须记得把配置文件里刚才加的 innodb_force_recovery = 6 这一行注释掉或者删除掉，如果不删，数据库会一直处于只读的恢复模式。

4. 重新启动MySQL：用正常的模式启动MySQL，这一次，因为密钥环的路径正确了，MySQL在启动时就能用正确的密钥解密那张出问题的表，启动过程就顺利完成了。

5. 事后检查：启动成功后，我们立刻连接上去，检查了一下那张之前报错的表，确认数据可以正常查询，没有丢失，同时也检查了其他重要的业务表，确保万无一失。

总结一下核心思路

整个处理过程,其实就是“定位问题 -> 规避问题（强制启动）-> 修复根源（密钥配置）-> 恢复正常”这么一个流程，遇到ER_DES_FILE_WRONG_KEY，不要想着去破解加密，而是要回想一下最近对服务器或配置做了什么改动，重点检查密钥环的配置和文件是否完好，强制恢复模式（innodb_force_recovery）是在这种紧急情况下一个非常有用的“救命稻草”，但它是一把双刃剑，使用一定要谨慎。

希望这个真实的排查经历,能对可能遇到类似问题的朋友有所帮助，数据库运维无小事，尤其是动配置和做迁移的时候，一定要细心，并且做好备份。