P1 滚动维护/升级
MongoDB 副本集的维护/升级通常以滚动方式执行，依次在辅助节点上执行维护，而最后执行主节点维护。
- 在辅助节点上停止MongoDB服务，执行运维操作
- 在服务器上启动MongoDB服务
- 等待节点的MongoDB同步到最新的Oplog（追赶）
- 在副本集中的其他辅助节点上重复上述操作
假定一个副本集包含mon01（主节点），mon02（辅助）mon03（辅助），滚动运维通常需要：
- 先后在辅助节点mon03、mon02上进行维护
- 将主节点mon01降级（stepDown），等待选举新主节点，比如说mon02
- 在以前的主节点mon01上执行维护
如果主服务器意外终止/大多数辅助节点觉得与主节点失联，则辅助节点会在丢失心跳10秒钟后要求进行选举。
P2 快速选举
主节点降级，触发快速选举
退出（stepDown）主节点可加快故障转移过程，建议使用stepDown命令退出主节点以强制触发选举，而不是关闭（shutDownServer）主数据库 (辅助节点需花时间识别主节点失联)
减少electionTimeoutMillis阈值
辅助节点认定主节点失联的默认阈值是10s， 在滚动维护期间我们可人为缩短这个阈值，加快选举。但是运维完毕，请恢复这个默认设置。
rs.isMaster().me // mon02:27000 // rs0:PRIMARY> // on the new primary var conf = rs.conf() conf.settings.electionTimeoutMillis=10000 /* rs.reconfig(conf) { "ok": 1, "operationTime": Timestamp(1529034252, 1), "$clusterTime": { "clusterTime": Timestamp(1529034252, 1), "signature": { "hash": BinData(0, "AAAAAAAAAAAAAAAAAAAAAAAAAAA="), "keyId": NumberLong(0) } } } */
“10s的阈值是合适的，我们要确保集群能够忽略和忍耐网络抖动或网络延迟， 减少不必要的重选。
P3 优选新主节点
一般情况下，会根据如下因素选择 主节点
- 低复制滞后
- 低网络延迟
若想指定某辅助节点mon02为下一个主节点，在其他辅助节点上运行rs.freeze（60）冻结它们成为主节点的资格；当你stepDown主节点mon01时，辅助节点mon02是唯一可以选择的主节点，这将加快选举速度。
或
您可以通过给予副本集成员比其他成员更高的member [n] .priority值来使其成为主节点。
cfg = rs.conf() cfg.members[0].priority = 0.5 cfg.members[1].priority = 0.5 cfg.members[2].priority = 1
