MongoDB 集群的 keyFile 可以实现无停机轮换，但前提是必须严格遵循「双密钥共存 → 逐节点重启 → 清理旧密钥」这三步流程。任何一步被省略，都可能造成节点失联、集群认证失败或服务异常；原因在于 mongod 启动时只会读取一次 keyFile，运行过程中不会自动重载，而节点之间的双向认证又要求通信双方至少共享一个可用密钥，否则握手一定失败。
MongoDB keyFile 支持不停机轮换，但必须严格按照「双密钥共存 → 逐节点重启 → 清理旧密钥」执行。只要跳过其中任意一个环节，就很容易引发节点认证失败、成员掉线，甚至影响整个副本集或分片集群的稳定性。
为什么不能直接替换密钥文件？
首先要明确：mongod 进程在启动时只会读取一次 keyFile，服务启动完成后并不会在运行期间重新加载这个文件。与此同时，MongoDB 的 keyFile 认证属于双向校验机制——也就是说，如果某一端已经切换为新密钥，而另一端仍然只保留旧密钥，那么在建立连接和握手时就会直接失败。常见错误通常表现为：no valid authentication method found 或 Unable to authenticate using SCRAM-SHA-256。很多场景下看起来像是 SCRAM 认证异常，但真正的根本原因，其实往往是 keyFile 校验不通过。
核心在于：MongoDB 的密钥文件支持多密钥共存。只要通信双方的 keyFile 中至少有一个相同密钥，节点间认证就可以正常通过。这也是 MongoDB 集群进行无停机滚动轮换 keyFile 的唯一基础。
- 密钥文件内容必须为 base64 编码的纯文本格式，每行写一个密钥，不能包含空行、注释或多余字符
- 生成新密钥时必须使用
openssl rand -base64 756（MongoDB 对 keyFile 长度要求 ≥ 756 字节） - 旧密钥与新密钥必须同时写入所有节点的同一个 keyFile 中，顺序可以不同，但内容必须一致
如何安全重启每个节点？
MongoDB 节点的重启顺序与操作方式，会直接影响集群可用性和业务连续性。不能简单使用 kill -9 或直接 systemctl restart，否则可能引发主从切换异常、选举抖动，甚至造成写入中断。
针对副本集成员（包括分片副本集以及配置服务器 CSRS），推荐按以下方式逐个重启：
- 从节点：连接
mongosh，执行use admin→db.shutdownServer()，然后再手动启动实例 - 主节点：先执行
rs.stepDown()让当前主节点降级，等待新主节点完成选举且状态稳定（rs.status().myState === 2），再执行db.shutdownServer() - mongos 实例：可以直接执行
db.shutdownServer()，因为它不参与副本集投票，重启通常不会影响分片路由与数据分布逻辑
需要注意的是：db.shutdownServer() 属于优雅关闭，会等待当前操作处理完成后再退出；而 kill -2（SIGINT）虽然效果基本一致，但在生产环境中不如命令方式更直观、可控，也不便于标准化运维。
清理旧密钥时最容易踩的坑
在第二轮重启之前，如果遗漏了任意节点的 keyFile 清理，该节点仍会继续接受旧密钥。表面上看服务似乎正常，但实际上已经留下明显的安全风险；更麻烦的是，如果某个节点漏掉了第二轮重启，它可能只识别新密钥，而其他节点仍处于双密钥阶段，最终导致该节点无法正常加入集群，甚至被集群剔除。
- 务必确认所有节点上的 keyFile 内容已经**仅保留新密钥一行**（可使用
wc -l进行核对） - 检查
mongod.conf中security.keyFile配置路径是否正确指向目标文件（常见问题包括：软链接未更新、文件路径拼写错误） - 节点重启后应立即验证：
rs.status().members[n].stateStr是否全部为PRIMARY/SECONDARY，不能出现REMOVED或UNKNOWN
还有一个很容易被忽略的关键点：keyFile 轮换完成后，所有客户端连接池（例如 pymongo 的 maxPoolSize）并不会自动感知这次变更，但这通常不影响业务连接，因为 keyFile 只用于 mongod 与 mongos 之间的内部认证，不影响客户端直连访问。这一点与 TLS 证书轮换完全不同，因此一般不需要额外重连应用程序。
