MongoDB副本集priority 0节点的Oplog大小是否需与可当选主节点一致

结论先行 #

即便设置为永远无法选主的priority 0节点，Oplog大小依然非常重要；即使禁用链式复制强制所有节点仅从主节点同步，也不建议给这类节点设置过小的Oplog。

核心原因说明 #

• 首先纠正一个理解误区：节点宕机后能不能正常增量恢复，核心不是节点自身有没有保存最新操作记录，而是你的同步源（不管是主节点还是其他从节点）是否还保留了从该节点最后一条Oplog记录之后的所有连续操作。如果priority 0节点的Oplog很小，意味着它能容忍的最大离线时间极短：比如Oplog仅能存储1小时的业务写操作，只要节点因为维护、故障等原因离线超过1小时，主节点的Oplog已经滚动覆盖了1小时前的操作，这个节点就算是priority 0，也无法增量恢复，必须执行全量重同步，全量同步会占用大量集群带宽、节点IO资源，对业务影响远大于多分配一点磁盘空间给Oplog。
• 即便禁用链式复制，还有很多依赖Oplog保留时长的场景：比如用priority 0节点做离线备份、数据导出、分析查询，你需要从该节点拉取Oplog做增量备份，Oplog过小会导致备份间隔稍长就无法获取连续的增量日志，只能做成本更高的全量备份；另外如果集群发生主节点故障转移，新选举出的主节点Oplog容量可能小于原主节点，原主节点能保留7天的Oplog，新主可能仅能保留3天，这时如果priority 0节点的Oplog很小，离线时间稍长就会出现新主Oplog已覆盖该节点最后操作的情况，依然需要全量重同步。
• 即使你完全不需要链式复制、也不用priority 0节点做备份，小Oplog也会带来额外风险：比如集群主节点带宽被业务写打满时，你可以临时放开链式复制规则，让其他从节点从负载较低的priority 0节点同步数据，降低主节点压力，如果priority 0节点Oplog过小，很容易出现同步中断的情况，相当于少了一个重要的容灾调优手段。

目前磁盘存储成本很低，Oplog设置为至少能保存7天的业务写操作是行业通用的最佳实践，完全没必要为了省一点磁盘空间给priority 0节点设置过小的Oplog，反而带来更多运维风险。

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