MongoDB在企业级部署中越来越多地依赖静态加密（Encryption at Rest）来保护数据安全，但加密机制一旦配合异常关闭、文件损坏或密钥管理失误，就可能触发错误码2660（UnrecoverableShutdownError）。这个错误会直接导致mongod进程无法启动，索引无法通过完整性校验，属于比较严重的一类故障。要正确处理它，需要先理解加密存储在MongoDB内部是如何工作的。
错误码2660的产生原理与底层机制
MongoDB企业版通过WiredTiger存储引擎的扩展加密能力实现静态加密。当启用加密后，数据文件和索引文件在磁盘上以密文形式存在，所有的加解密操作都由存储引擎层完成，对上层业务透明。密钥管理采用三级结构：主密钥（Master Key）存放在密钥文件中，由主密钥派生出各个数据密钥（Data Key），再由数据密钥对具体的表和索引文件进行加密。
错误码2660的本质是实例在异常关闭后，恢复流程无法完成重放（Replay）和校验。WiredTiger使用预写式日志（WAL）保证持久性，正常关闭时会将日志完整落盘并标记干净的关闭状态。但如果进程被强制kill、操作系统崩溃或磁盘出现坏块，下次启动时存储引擎需要执行崩溃恢复，重放日志并校验加密元数据。此时如果密钥不匹配、KeyStore结构损坏或日志中记录的加密密钥ID在KeyStore中找不到，校验就会失败，mongod以2660错误退出。
一个容易被忽视的细节是：索引文件和集合文件的加密密钥是独立的。索引的B树结构在加密后，其页面的校验和（checksum）计算发生在密文层面。如果密钥错误但文件结构本身完好，引擎可能会判定为校验失败而不是密钥错误，这会让日志中的报错看起来模棱两可，增加排查难度。
常见触发场景与日志定位方法
实际生产中，2660错误主要出现在以下几种场景：第一种是密钥文件丢失或路径配置错误，比如运维人员迁移了数据目录但忘记同步密钥文件；第二种是密钥文件被错误轮换，新密钥无法解密旧数据；第三种是启用加密的实例被非正常关闭，且日志文件损坏导致恢复中断；第四种是版本升级后加密元数据格式变化，比如从旧版本直接拷贝数据文件到新版本环境。
定位问题首先要看mongod日志。典型的2660错误日志会包含类似下面这样的输出：
{
"s": "F",
"c": "CONTROL",
"id": 20574,
"msg": "UnrecoverableShutdownError",
"code": 2660,
"attr": {
"error": "WiredTiger error (-31802): __wt_block_read_off, ... encryption failure"
}
}
日志中如果出现encryption failure或unable to locate decryption key for id字样，基本可以确认是加密层面的问题，而不是单纯的索引损坏。此时需要检查mongod的启动配置，重点确认以下几个参数：encryptionKeyFile指向的路径是否正确、文件权限是否为600、所属用户是否为mongod进程用户。如果使用的是KMIP服务器管理密钥，则要检查KMIP连接配置和证书状态。
还可以通过查看WiredTiger.wt和WiredTigerHS.wt等元数据文件的修改时间，判断实例上次关闭是否正常。这些文件的最后写入时间与日志中记录的关闭时间如果不一致，说明数据目录存在被二次写入的风险，切忌在未确认前反复重启实例。
完整的故障恢复操作流程
确认是密钥问题后，恢复工作的第一步是找到正确的主密钥。可以从备份系统中检索密钥文件的历史版本，或者从KMIP服务器查询对应的密钥对象。找到候选密钥后，不要直接覆盖现有配置，先用只读方式验证密钥的正确性。一种稳妥的做法是将当前数据目录完整复制一份，在副本上用候选密钥启动，观察是否能正常恢复：
# 复制数据目录到测试环境 cp -a /data/mongodb /data/mongodb_recover chown -R mongod:mongod /data/mongodb_recover # 用候选密钥在测试端口启动 mongod --dbpath /data/mongodb_recover \ --encryptionKeyFile /backup/keys/mongodb-keyfile-v3 \ --port 28018 --logpath /var/log/mongod_recover.log --fork
如果测试实例能够正常启动，说明密钥匹配，接下来可以对索引做一致性检查。连接到恢复实例后，使用validate命令逐个检查可疑集合：
// 检查集合及索引的完整性
db.getSiblingDB("orderdb").runCommand({
validate: "orders",
full: true,
checkBTree: true
})
validate的结果会列出损坏的索引名称和错误详情。对于校验失败的索引，最安全的处理方式是删除后重建，而不是尝试修复：
// 删除损坏索引
db.orders.dropIndex("idx_create_time")
// 重建索引，后台方式避免阻塞业务
db.orders.createIndex(
{ create_time: 1 },
{ background: true, name: "idx_create_time" }
)
如果密钥确实无法找回，那么加密数据在数学上不可恢复，只能依赖备份重建数据目录。这种情况下应立即停止对原数据目录的一切写入操作，将目录完整归档留作分析，然后按照备份恢复流程重建实例。恢复完成后务必验证业务数据的完整性，再对外提供服务。
预防此类故障的实践建议
加密存储故障的代价很高，预防工作远比事后修复重要。首先是密钥备份策略，密钥文件应当与数据备份同等对待，采用异地多重备份，并定期演练密钥恢复流程。建议在每次密钥轮换后，在隔离环境中用新密钥启动一次实例做冒烟测试，确认全部数据可解密后再淘汰旧密钥。
其次是关闭流程的规范化。运维操作中应严格使用db.shutdownServer()或systemctl stop mongod来停止实例，避免直接kill -9。对于必须快速终止的场景，也要确保日志文件所在磁盘有足够空间，因为WAL日志写满同样会导致恢复失败。可以将日志目录与数据目录放在不同的存储设备上，降低连带损坏的概率。
最后是监控层面的建设。可以对mongod日志中的WiredTiger关键字做实时采集告警，对WT_PANIC、encryption相关的日志条目设置高级别告警。同时结合文件系统监控，关注WiredTiger元数据文件的异常变更。这一套组合措施能让你在故障真正发生前捕捉到苗头，把不可恢复的2660错误拦截在萌芽阶段。
MongoDB错误码2660索引加密存储MongoDB故障排查修改时间：2026-09-08 13:37:07