I understand the Oplog collection in MongoDB replica set. A bigger Oplog means a bigger recovery window when a data bearing node goes down.

However for nodes that can never be primary, is the Oplog size important?

The rule to recover a node that went down was that its newest operation in its Oplog will also be currently found in the primary node's Oplog. Since the primary node Oplogs is big, and the newest operation of the node that we try to recover is the last operation that was recorded in its Oplog(and that can be tracked even with a very small Oplog), does it really matter the size of the "priority 0" nodes Oplog?

I understand that a secondary, priority 1 node, could copy new contents in its Oplog from any other data-bearing node by default (even it that node has priority 0), however is that the only reason to keep a big Oplog on a priority 0 node? If so, just disabling that option and forcing data-bearing nodes to replicate only from the primary node would allow me to have a small Oplog in a priority 0 node.

1 Answer 1


Yes , we need to have same oplog size similar to the primary member.

Priority 0 members have the current copy of the data and they can never become primary. It can be used as a hidden or delayed member from the application and used for its purpose.

In case due to some disaster all other nodes goes down in your replica are down, you can promote this priority 0 member to prioriy 1 manually and make it as a working primary. This is why we need to have same oplog size & data size similar to the primary. It's a kind of invisible safe backup instance.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.