MongoDB副本集隐藏节点Oplog配置规则及大文件存储占用问题

关于MongoDB副本集Oplog两个核心疑问的解答 #

疑问1：大文件写入的双份存储、Oplog滚动规则与全节点生效范围 #

• 空库首次写入50GB图片的阶段，确实会存在双份存储：所有写入操作的完整内容都会被记录到主节点的Oplog中，此时主节点会同时在实际数据文件、Oplog文件中各存储一份这50GB的图片数据。如果你的图片体积超过单文档16MB上限、使用GridFS拆分存储，每个拆分后的chunk块写入操作也会单独记录Oplog，整体存储逻辑和普通文档一致。
• Oplog是固定大小的循环日志，当占用量达到你配置的50GB阈值后，会自动滚动覆盖最旧的日志条目，Oplog总大小不会再持续增长，只有实际业务数据的存储容量会随写入持续扩容。
• 该存储规则对副本集所有数据节点（主节点、从节点、隐藏节点）均生效：从节点和隐藏节点会拉取主节点的Oplog写入到本地的Oplog集合，同时将操作应用到本地数据文件，因此所有数据节点都会存在数据文件+对应Oplog的双份存储，直到Oplog写满后滚动覆盖。

疑问2：隐藏节点的Oplog大小配置要求 #

隐藏节点的Oplog大小强烈建议和主、从节点保持一致，核心原因如下：

• 隐藏节点需要持续从主节点拉取Oplog完成数据同步，如果隐藏节点Oplog容量小于主节点，可能出现主节点已经覆盖了旧Oplog、但隐藏节点还没拉取到该部分日志的情况，直接导致隐藏节点同步中断，需要执行全量重同步才能恢复。
• 即使隐藏节点不会被选举为主节点，后续如果遇到主从节点故障恢复、从隐藏节点拉取备份、调整副本集角色等场景，Oplog大小一致可以避免大量不必要的同步故障。
• 仅当你的隐藏节点仅作临时离线备份、可接受同步中断后直接重建的成本时，可酌情调小Oplog，该操作不属于推荐方案。

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