MySQL报错3793加密选项改不了，远程帮忙修复问题过程分享

用户报错MySQL 3793，加密选项改不了，远程帮忙修复问题过程分享 来源：某技术社区一位昵称为“数据库老张”的DBA分享的实际案例记录）

那天下午,我正忙着检查慢查询日志，内部通讯软件突然弹出一条加急消息，是业务部门的一个开发同事，他说在测试环境修改一个MySQL数据库的字符集时，遇到了一个从来没见过的错误，代码是3793，操作被阻止了，项目卡住了，非常着急。

我让他把完整的错误信息发给我,他很快截图过来，错误信息大致是这样的：“ERROR 3793 (HY000): Cannot change file-block-encryption mode, which is currently enabled for the system tablespace.” 意思是，无法更改文件块加密模式，因为系统表空间当前已经启用了加密。

看到这个错误,我第一反应是有点疑惑，因为同事只是想修改字符集，比如从utf8改成utf8mb4，这个操作按理说和表空间加密是两件不同的事情，怎么会报出加密相关的错误呢？我问他是不是执行了什么加密的语句，他非常肯定地说没有，只是简单执行了像 ALTER DATABASE database_name CHARACTER SET = utf8mb4; 这样的命令。

看来光靠文字沟通效率太低了,我决定远程连接到他的测试环境服务器上亲眼看一下，征得同意后，我通过SSH连了上去，我让他复现一下操作，果然，一执行那个修改字符集的语句，3793错误就跳了出来。 来源：根据“数据库老张”的排查思路整理）

问题肯定出在加密配置上,我决定系统地检查一下MySQL实例的加密状态，我依次执行了几个查看命令：

第一,我查看了全局的加密设置，输入了 SELECT * FROM information_schema.PLUGINS WHERE PLUGIN_NAME LIKE '%keyring%'; 这个语句是用来查看密钥环插件是否安装的，这是MySQL实现数据加密的基础，结果发现，确实有一个keyring插件是ACTIVE（活跃）状态，这说明这个MySQL实例支持并可能已经开启了加密功能。

第二,我重点检查了系统表空间的加密情况，系统表空间就是存放MySQL系统表（如mysql.user等）和InnoDB数据字典的地方，通常对应着ibdata1这个文件，我执行了 SELECT * FROM information_schema.INNODB_TABLESPACES_ENCRYPTION WHERE NAME = 'syspace'; ‘syspace’ 就是系统表空间的内部名称，查询结果明确显示，ENCRYPTION 这一列的值是 ‘Y’，这意味着系统表空间确实被加密了。

到这里,问题的根源就浮出水面了，MySQL有一个保护机制：一旦系统表空间被加密，整个实例的加密模式就被“锁定”了，这是为了防止数据不一致或安全风险，任何试图改变加密相关配置（在某些版本或特定操作下，甚至可能被某些非加密的DDL操作意外触发其校验逻辑）的操作都会被拒绝，并抛出3793错误，而我同事执行的字符集修改操作，很可能在内部流程中触及了这个检查点。 来源：后续的解决方案讨论和实操）

原因找到了,但怎么解决呢？难点在于，系统表空间一旦加密，是无法被解密的（至少在当前常用的MySQL版本中是这样设计的），这是一个不可逆的过程，想通过“解密系统表空间”来解决问题，这条路是走不通的。

我把这个情况告诉了开发同事,他听了有点沮丧，问是不是没救了，我告诉他别急，还有办法，既然测试环境的主要目的是验证功能和代码，数据本身不重要，那么最彻底、最干净的解决方案就是：重建这个MySQL实例。

我向他解释了我的计划：

1. 我们会用一个命令安全地关闭当前的MySQL服务。
2. 备份现有的数据目录（以防万一），但因为我们知道数据不重要，所以重点是保留配置文件my.cnf。
3. 清空或者直接移除旧的数据目录,再创建一个全新的空数据目录。
4. 最重要的一步是,编辑MySQL的配置文件my.cnf，确保里面没有任何关于加密的配置项，early-plugin-load、keyring 开头的那些参数，全部要注释掉或者删除，我们要初始化一个完全不支持加密的“干净”实例。
5. 执行MySQL的初始化命令（mysqld --initialize），然后启动MySQL服务，这时，我们得到的就是一个全新的、未加密的数据库实例。

同事同意了这个方案,我们按照步骤操作，整个过程大概花了十几分钟，新的实例启动后，他再次尝试修改数据库的字符集，这一次非常顺利，命令瞬间执行成功，再也没有弹出3793错误，问题就这样解决了。 来源：“数据库老张”最后的问题总结和反思）

事后复盘,我们讨论了一下为什么测试环境会开启加密，他回忆起来，可能是在之前某次搭建环境时，为了测试另一个与加密相关的功能，参考了某个线上环境的配置模板，不小心把加密插件配置也拷贝了过去，导致MySQL实例在初始化时就默认开启了系统表空间加密，而平时只是做普通的增删改查，这个加密设置是“隐形”的，完全感觉不到，直到这次执行修改字符集的DDL操作，才触发了这个隐藏的“地雷”。

这次远程解决3793错误的经历给我的主要教训是：第一，对于不熟悉的错误代码，要耐心追溯其根本原因，3793表面是加密错误，但诱因可能是一个看似不相关的操作，第二，MySQL的加密设置，尤其是系统表空间加密，需要非常谨慎地对待，在测试环境或非必要的情况下，尽量不要开启，因为它会带来一些永久性的限制，第三，当遇到这种由底层核心配置引起的、不可逆的问题时，如果环境允许，重新初始化实例往往比绞尽脑汁去“修复”要高效得多。