如何零停机更新即将过期的Mongo集群SSL证书

当然有零停机更新SSL证书的方法！我之前帮不少团队处理过这个场景，只要遵循滚动更新的步骤，配合合理的配置过渡，完全可以做到服务不中断，不用停掉整个集群。下面是具体的操作流程，我分阶段给你拆解：

前期准备 #

• 生成新的SSL证书套件：包括新的CA证书、每个节点的服务器证书/密钥，确保新证书的CN/SAN和旧证书一致，或者覆盖集群节点的主机名、IP等身份验证所需信息。
• 将旧CA证书和新CA证书的内容合并到同一个文件（比如命名为combined-ca.pem），这样集群节点会同时信任新旧CA签发的证书，这是实现滚动更新的关键过渡配置。
• 备份当前所有节点的旧证书文件和MongoDB配置文件，防止操作失误时可以快速回滚。

第一阶段：配置集群兼容新旧证书 #

1. 把合并后的combined-ca.pem上传到每个集群节点的证书目录（比如/etc/mongodb/ssl/），确保MongoDB运行用户对该文件有读取权限。
2. 这个步骤可以和后续的证书替换合并操作，不用单独重启节点，减少不必要的服务中断风险。

第二阶段：滚动更新集群节点证书 #

按照次要节点→主节点的顺序逐个处理，确保每次只操作一个节点，等它完全恢复并同步完成后再处理下一个：

处理次要节点（Secondary） #

• 登录目标节点，停止MongoDB服务：sudo systemctl stop mongod
• 替换节点的服务器证书（比如server.pem）和密钥文件（比如server-key.pem）为新的文件，确保权限正确（通常是mongodb:mongodb拥有，权限设为600）。
• 启动MongoDB服务：sudo systemctl start mongod
• 等待节点重新加入集群，通过rs.status()确认该节点状态变为SECONDARY，且optimeDate接近当前时间（同步正常）后，再处理下一个次要节点。

处理主节点（Primary） #

• 连接到主节点，执行降级命令：rs.stepDown(600)（600为选举超时时间，单位秒，给集群足够时间选出新主）
• 通过rs.status()确认集群已选出新主节点后，再操作原主节点：停止服务、替换新证书/密钥、启动服务。
• 原主节点重启后会自动以次要节点身份加入集群并同步数据，后续可以手动执行rs.stepUp()将它重新提升为主节点，或者让集群自动选举。

第三阶段：切换到仅信任新CA证书 #

等所有节点都完成新证书替换，且集群稳定运行一段时间后，我们可以移除旧CA的信任：

• 上传仅包含新CA的证书文件（比如new-ca.pem）到每个节点。
• 再次滚动重启每个节点：停止服务，修改net.ssl.CAFile配置为new-ca.pem，启动服务，确保每个节点正常加入集群。

客户端侧的零停机更新 #

客户端也要配合过渡，避免连接中断：

• 先将客户端的CA配置改为使用合并后的combined-ca.pem，确保客户端同时信任新旧证书。
• 滚动更新客户端的证书/密钥为新文件，分批重启客户端实例（如果是长连接应用，可优先选择支持证书热加载的客户端库，减少重启次数）。
• 所有客户端更新完成后，再将客户端的CA配置改为仅使用新CA证书。

注意事项 #

• 确保MongoDB版本支持滚动更新：建议使用3.2及以上版本，这类版本在集群滚动重启时的可用性更有保障。
• 操作过程中密切监控集群状态：通过rs.status()、MongoDB日志、监控工具跟踪节点状态和同步进度，出现异常及时回滚。
• 证书权限一定要正确：MongoDB运行用户必须能读取证书文件，否则节点启动会失败。

内容的提问来源于stack exchange，提问作者Chris Powell