, free & fully virtual. Register Now, free & fully virtual. Register Now

Write concern behavior with in-memory storage?

Hi there,

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”:

Thank you!

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. :slight_smile:

Hi @JEC welcome to the community!

I believe your questions are answered in the Durability Section of the In-Memory Storage Engine page.

As you mentioned (and also mentioned in the linked page above), if any voting member of a replica set uses the in-memory storage engine, you must set writeConcernMajorityJournalDefault to false.

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.

Best regards,

1 Like

Thanks so much Kevin. Yes, understood about potential roll back implications.