KeyFile不可集中备份，因MongoDB禁止多进程同时打开同一文件，否则触发unable to lock key file错误；其安全性依赖机密性与独立性，须分发后隔离存储、严格权限（chmod 400）、绝对路径引用，并纳入部署流水线管理。

keyfile 不能备份成“一份通用副本”——它必须是每个节点独立保管、不可共享、不可复用的密钥文件。

为什么 keyfile 不该被集中备份？

MongoDB 明确禁止多个 mongod 进程同时打开同一份 keyfile。一旦你把同一个文件通过 scp 或 NFS 同步到多个节点，或在备份系统里存为“统一模板”，就可能触发 unable to lock key file 错误，导致集群启动失败。

keyfile 的本质是节点间通信的对称密钥，不是密码，也不是证书；它不加密数据，只用于集群内部身份校验。它的安全性依赖于“机密性 + 独立性”：每个节点上的 keyfile 内容可以相同（通常就是相同），但文件路径、权限、访问控制必须隔离。

• 内容可一致（比如都用 openssl rand -base64 741 > keyfile 生成一次，再分发）
• 路径必须不同（例如 A 节点是 /data/mongodb/keyfile，B 节点是 /opt/mongodb/keyfile）
• 权限必须严格（chmod 400，且属主为运行 mongod 的用户，如 mongodb）
• 绝对不能挂载自同一 NFS 目录，也不能由容器共享 volume 统一挂载

生产环境该怎样“备份”keyfile？

这里的“备份”不是指冷拷贝一份放云盘，而是指：确保某节点故障后，能快速恢复其合法、可用的 keyfile，且不破坏集群安全模型。

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

• 原始生成命令和参数必须记录在配置管理库（如 Ansible Vault、HashiCorp Vault）中，而非保存明文文件
• 若已生成并分发，应将每个节点的 keyfile 单独加密归档（例如用 gpg --symmetric --cipher-algo AES256 keyfile），并标注节点 IP 和用途（如 shard1-node1-keyfile.gpg）
• 严禁把未加密的 keyfile 放进 Git、NAS 共享目录、邮件或聊天工具
• 备份存储位置需与 MongoDB 数据目录物理隔离（例如不放在 /data/mongodb/ 下，也不在同块磁盘）

启动时引用 keyfile 的常见错误

即使 keyfile 文件存在且权限正确，启动仍会失败，往往是因为遗漏了配套参数：

• --auth 必须启用，否则 keyFile 不生效
• --clusterAuthMode keyFile 必须显式指定（MongoDB 3.6+ 默认是 sendKeyFile，但分片集群要求 keyFile）
• keyFile 路径在配置文件中要写全路径，且 mongod 进程必须有读取权限（注意：Docker 容器内运行时，宿主机映射路径和容器内路径需一一对应）
• 使用 systemd 启动时，检查 LimitNOFILE 和 UMask=0077 是否影响文件打开权限

最易被忽略的一点：keyfile 的备份动作本身，必须在集群停机窗口外完成——你不能为了“备份 keyfile”而临时改权限、复制文件、上传到对象存储，这些操作都可能暴露密钥或干扰锁机制。真正可靠的方案，是把它纳入部署流水线，在节点初始化阶段就生成、分发、落盘、加固，之后不再触碰。