Hello @Jerome_Pasquier ,
Welcome back to The MongoDB Community Forums! ![]()
As per the documentation on Oplog Size
In most cases, the default oplog size is sufficient. For example, if an oplog is 5% of free disk space and fills up in 24 hours of operations, then secondaries can stop copying entries from the oplog for up to 24 hours without becoming too stale to continue replicating. However, most replica sets have much lower operation volumes, and their oplogs can hold much higher numbers of operations.
Before
mongodcreates an oplog, you can specify its size with theoplogSizeMBoption. Once you have started a replica set member for the first time, use thereplSetResizeOplogadministrative command to change the oplog size.replSetResizeOplogenables you to resize the oplog dynamically without restarting themongodprocess.New in version 4.4: Starting in MongoDB 4.4, you can specify the minimum number of hours to preserve an oplog entry. The
mongodonly truncates an oplog entry if:
- The oplog has reached the maximum configured size, and
- The oplog entry is older than the configured number of hours based on the host system clock.
By default MongoDB does not set a minimum oplog retention period and automatically truncates the oplog starting with the oldest entries to maintain the configured maximum oplog size.
See Minimum Oplog Retention Period for more information.
Of course, the more oplog window you can have the better. However, anecdotally, I would say that a good value is perhaps something that can cover the weekend, in case something happened to your cluster during the weekend period. Realistically, it should be able to comfortably cover any planned maintenance window length you’re planning to have.
I would recommend you to kindly go through below mentioned documentation and thread to learn about Alert conditions, Common Triggers and Fix/Solution for Oplog Issues.
Regards,
Tarun