@saurav_gupta Increased oplog sizing will buffer more write operations for replication, but if your continuous write load is outpacing how quickly writes can be replicated and applied on your secondaries, this will not address the underlying problem. You should also review your deployment metrics and consider whether your replication throughput is being limited by resources such as network or I/O bandwidth.
If you want to ensure reliable replication to secondaries, you need to throttle writes to what can reasonably be replicated to your secondaries given the buffer provided by your oplog sizing.
If you can upgrade to MongoDB 4.2, there’s a new replication flow control feature which is enabled by default and provides administrative control over the maximum secondary lag before queueing writes on the primary. This would impose a similar effect to using a majority write concern but with a bit more tolerance on acceptable lag as well as server-side admin control. This feature has an associated group of flowControl metrics in serverStatus that provides more insight into the activity on the primary.
@Kanishka_Ramamoorthy Please create a separate thread if you’d like to discuss issues specific to your deployment and use case.
Changing write concern to w:0 will make a replication throughput problem even worse: you’ll be writing without any acknowledgement and sending requests at the primary as fast as possible. If you have continuous writes this will exacerbate any problems due to secondary lag (your application isn’t even waiting to confirm the primary accepted the write).
Regards,
Stennie