MongoDB 企业版提供加密存储引擎，当节点启用加密后，WiredTiger 依靠本地密钥库文件对磁盘上的数据进行加解密。如果该文件损坏，mongod 进程会在启动阶段报出 2090 错误并退出。该问题常见于配置文件复制、磁盘故障或备份恢复后权限异常。
2090 错误码并不是 MongoDB 官方公开错误码文档中的常见编号，但是在使用本地密钥管理方式的企业部署中，它通常对应本地密钥库读取失败这一类启动异常。理解这个错误的前提是弄清楚加密存储引擎的依赖关系：数据目录中的加密集合无法在没有密钥库的情况下被解密，因此 mongod 必须保证在读取任何加密集合之前能够完整、安全地加载密钥库文件。
一、认识 2090 错误码：密钥库损坏到底指什么
本地密钥库是 MongoDB 加密存储引擎的核心依赖。启用加密后，security.enableEncryption 会要求指定 encryptionKeyFile，这个文件通常是一个二进制或 Base64 编码的随机数据文件。如果文件本身长度为 0、内容被截断、包含多余换行符或者被误写入文本，mongod 在启动时无法正确将其解析为可用密钥，就会拒绝继续初始化，并抛出 2090 错误。
除了内容损坏，权限和属主错误也会表现为同样的故障码。出于安全考虑，MongoDB 会检查密钥库文件的访问权限。Linux 平台上一般要求密钥文件权限为 600，属主为运行 mongod 的用户。如果权限过于开放，例如设置为 644 甚至 777，mongod 会认为密钥库存在泄露风险而拒绝读取。文件路径配置错误、软链接指向异常、文件系统挂载丢失等情况，也会触发相同的错误提示。
另一个容易被忽略的场景是节点迁移。将数据目录和配置文件从一台服务器复制到另一台服务器时，如果只复制了数据目录而忘记复制 keyfile，或者复制过程中使用文本模式传输二进制文件导致内容发生改变，都会让新节点在启动时直接报出 2090。这说明加密存储引擎的恢复不仅仅是数据文件恢复，密钥库也必须作为同等重要的备份对象来管理。
二、故障排查：逐步确认密钥库状态
当 mongod 启动失败并出现 2090 错误时，第一步应查看配置文件中 encryptionKeyFile 指向的路径是否真实存在。可以使用 ls -l 查看文件是否存在、大小是否合理。正常情况下，一个本地密钥库文件不应该是 0 字节，也不应该是一个只有几个字节的纯文本文件。如果文件大小明显异常，基本可以判定为损坏。
ls -l /etc/mongodb/keyfile od -c /etc/mongodb/keyfile | head -n 5
接下来需要检查文件权限和属主。以典型安装为例，mongod 用户应当拥有该文件，并且权限应为 600。如果权限不对，可以先通过 chmod 和 chown 调整，然后重新尝试启动。需要特别注意的是，不能因为启动失败就盲目放开权限，这样即使绕过启动检查也会留下安全风险。
chown mongod:mongod /etc/mongodb/keyfile chmod 600 /etc/mongodb/keyfile systemctl start mongod
如果文件路径、权限和属主都正常，但问题依旧存在，就需要检查文件内容是否完整。可以通过比对备份中的密钥库文件哈希值来确认当前文件是否发生过改变。例如使用 sha256sum 计算当前文件和备份文件的摘要，如果不一致则说明文件已损坏或被误修改。日志中往往会记录类似 Unable to read local key file 的详细信息，结合日志可以更快定位是读取失败还是校验失败。
三、修复方案：从备份恢复与重新配置
确认密钥库损坏后，最直接的恢复方式是使用备份文件覆盖当前损坏文件。停止 mongod 服务后，从可靠备份中复制 keyfile 到原路径，然后恢复正确的权限和属主。如果没有单独备份 keyfile，可以检查是否有整机备份、配置管理工具或密钥托管系统保留了该文件。复制时务必使用二进制安全的方式，避免使用 FTP 文本模式或某些网页上传工具传输二进制文件。
systemctl stop mongod cp /backup/mongodb-keyfile-20240701 /etc/mongodb/keyfile chown mongod:mongod /etc/mongodb/keyfile chmod 600 /etc/mongodb/keyfile systemctl start mongod
假如没有任何可用备份，问题会变得复杂。本地密钥库一旦完全丢失或不可恢复，而数据目录中又存在已经加密的集合，那么即使数据文件完好也无法解密读取。此时只能考虑从其他正常副本节点恢复数据，或者从更早的未加密备份重建实例。因此，在启用加密存储引擎的初期，就必须把 keyfile 纳入与数据文件同等重要的备份策略中。
修复完成后，需要验证节点是否已经正常加入副本集或分片集群。可以通过 rs.status() 或 sh.status() 检查节点状态，也可以查看 mongod 日志确认是否还有 2090 错误。对于单机实例，可以读取或写入一个测试集合来验证加密存储引擎是否正常工作。
四、避免再次损坏：密钥库管理规范
本地密钥库损坏多数与日常运维中的不规范操作有关。为了防止同一故障重复出现，建议将密钥库文件纳入配置管理和备份系统，并与数据文件分开保存。备份时不要只备份数据目录，还要单独备份 keyfile，并且定期演练恢复流程。密钥库文件的权限应保持为 600，属主为 mongod 用户，任何自动化脚本在复制或同步后都应显式设置权限和属主。
在节点迁移、升级或更换磁盘时，应当使用校验和确认文件传输后的完整性。例如在源端和目标端分别执行 sha256sum，如果摘要不一致则停止启动流程。不要使用可能改变二进制内容的传输方式，也不要通过邮件或即时通讯工具发送密钥库文件。对于安全要求较高的环境，可以考虑改用 KMIP 等外部密钥管理服务，将密钥与数据目录解耦，降低本地文件损坏带来的影响。
MongoDB 的加密存储引擎依赖的是一个长期的解密能力，而不是一个可以随时重新生成的临时配置。一旦密钥库缺失或损坏，数据恢复的代价远高于提前备份 keyfile 的成本。理解 2090 错误码背后的依赖关系，把密钥库当作一等公民来管理，是避免遭遇数据不可恢复风险的关键。
MongoDB故障码2090本地密钥库损坏加密存储引擎修改时间：2026-08-19 21:55:23