Apologies for such a simple question: does Mongo allow write concern with in-memory storage for sharded replica sets; for example “write concern: majority”?
I think the answer is “yes” since “writeConcernMajorityJournalDefault = false” must be set, in which case, “MongoDB acknowledges the write operation after a majority of the voting members have applied the operation in memory.”
Additionally journaling doesn’t apply, so the application must either not include “j” (journaling) in its write operation, or if it does specify, it must be set to “j=false”:
Hi, any answers or thoughts or other things to consider?
I did some brief experimentation with an in-memory 3-member replica set and it accepted “w: majority” without complaint. But hopefully it isn’t ignoring the request.
The write concern setting will still be honoured by the replica set. However, majority write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set. In a sense, since nothing is durable in a replica set using mostly in-memory storage engine, majority write is sort of meaningless. This is because the goal of majority-acknowledged write is to prevent rollbacks.
For more examples and use cases, please see the linked page above.