Hi @venkataraman_r welcome back!
The main reason for writeMajorityCount is that MongoDB is mainly designed to work as a replica set. To ensure writes won’t be rolled back is to have it propagated to the majority of voting nodes. However with arbiters this is tricky since an arbiter is a voting node with no data. See Implicit Default Write Concern for the formula when arbiters are involved.
- what are the internal mongo operations will have an impact due to this writeMajorityCount derivation by mongo itself.
dropDatabase() is one command that defaults to majority write concern. However I don’t think there’s a list of commands requiring majority write concern. Note that you can specify write concern for db.dropDatabase() but if you don’t it defaults to majority.
- My client application doesnt set any writeConcern. So my application code I’m sure it will not have an impact. But db.dropDatabase() command is getting stuck when one of the member is down.
I assume you’re using a PSA setup? This is expected since if the other data bearing member is down, the arbiter cannot acknowledge the write. Thus the command will just wait for a secondary acknowledgment that doesn’t arrive. The page Mitigate Performance Issues with PSA Replica Set would have more details into how to overcome this.
- So need to know what other internal mongo commands will have an impact. Will REPL has any issue if the majority is not available. Because we see high CPU usage once we move to 4.2. There is no changes except the mongo upgrade. So we need to know if this is having any role to play.
I think the increased CPU is tangent to the write concern issue you’re seeing. However the first port of call is usually ensuring you’re following the production notes for the optimal setup. The blog post Performance Best Practices: Hardware and OS Configuration might also be of interest to you.
we dont want to enable writeMajority .
Write concern majority becomes the default in MongoDB 5.0, since it provides much greater assurances that your writes won’t be rolled back. However this depends on your use case. I understand that some use case might not need the majority assurance since it’s ok if some data got rolled back and you need high writing speed.
However another advantage of write concern majority is that it provides a measure of control for data going into the replica set. Without this, it’s easy to overwhelm the servers with writes that it cannot replicate fast enough, leading to issues such as a secondary falling off the oplog.
Having said that, if you understand all the risks for disabling write concern majority, for most commands, you can specify a write concern setting to deviate from the default.
Hope this is useful!
Best regards
Kevin