Mongo集群Secondary节点安全重启及维护操作流程咨询

3节点及以上的MongoDB副本集场景下，短时关停Secondary节点不需要将其从集群移除，仅开启维护模式即可，移除节点会触发集群配置变更甚至选举，反而会对Primary造成更大影响。

完整操作流程 #

• 步骤1：登录到待维护的Secondary节点，执行命令开启维护模式

// 切换到admin库
use admin
// 开启副本集维护模式
db.adminCommand({"replSetMaintenance": true})

• 步骤2：验证维护模式生效
  执行rs.status()，查看当前节点的stateStr字段变为RECOVERING即代表生效，此时该节点会主动退出投票池、停止承接客户端读请求，避免下线后触发集群选举或流量调度异常。
• 步骤3：正常执行节点关停、维护操作即可。
• 步骤4：维护完成节点重启后，等待数据同步完成（执行rs.printSecondaryReplicationInfo()查看同步延迟归0）后，关闭维护模式恢复节点服务：

use admin
db.adminCommand({"replSetMaintenance": false})

执行后节点会自动恢复为SECONDARY状态，重新加入投票和承接读流量。

相关问题解答 #

1. 上述命令是否仅作用于执行该命令的那台特定Secondary节点？
   是，replSetMaintenance是节点级命令，仅对执行命令的当前节点生效，不会影响副本集内其他节点。注意该命令仅可在Secondary节点执行，在Primary节点执行会返回错误。
2. 维护时是否还需要将对应节点切换为hidden模式？
   不需要。hidden模式适用于长期不对外提供读服务、不参与主节点选举的专用节点（如备份节点），短时维护场景下使用维护模式已经可以满足需求，操作更轻量化，恢复成本更低。
3. 维护时是否还需要将对应节点切换为延迟副本模式？
   不需要。延迟副本是用于应对数据误删、故障回滚的专用节点配置，需要提前配置固定的同步延迟，和短时维护场景完全无关，修改该配置反而会增加不必要的集群配置变更开销，维护完成后还需要额外改回配置，不建议操作。

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