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.
The size of the Oplog does not have to be the same for all members, though it is recommended. You can configure the specific secondary to have a smaller oplig size, and then test the application with this database configuration.