I plan to have a big oplog size for primary and secondary nodes (stound 50GB), and a small oplog size for the hidden node.
The rationale behind it is that from the hidden node I will perform Filesystem Sanpshot backups in Linux. Therefore, I need to minimize the empty storage in the volume holding the database directory, so the backups do not store too much empty space. Additionally, a FS snapshot will take very long on a big logical volume, even though the volume might be empty.
Since a hidden node will never become primary, there is no chance that it will reduce the recover time of any other node due to its small oplog. Right?
Furthermore, if the hidden node goes down, it should recover nicely since:
- The “visible” (primary and secondary) nodes have a big oplog.
- Even if the hidden has a small oplog, the rule to catch up after a down time would be that the newest operation in the hidden oplog is also currently recorded in the primary’s oplog. Since the newest operation on the hidden node will be the last one inserted in its oplog, no matter how small its oplog is, that operation will be there.
Thus, the hidden node oplog can be very small. Am I missing something?