When using { w: 'majority', j: true }, the primary waits for a majority of voting members to confirm the write is in their on-disk journal before acknowledging the client, ensuring the write cannot be rolled back.
Write concern defines the level of acknowledgment requested from MongoDB for write operations . The combination { w: "majority", j: true } represents the strongest built-in durability guarantee in MongoDB. It requires that the write operation be durably persisted to the journal files of a majority of the replica set's voting members before the client receives acknowledgment . This ensures that even in the event of a catastrophic failure where the primary and several secondaries crash simultaneously, the write is not lost.
This setting provides a crucial guarantee: data acknowledged with { w: "majority", j: true } cannot be rolled back . This is because a majority of nodes have a durable, crash-proof record of the write. If the current primary fails, the write is already safely stored on the node that will become the new primary.
The w: "majority" option requires that the write has been applied to the calculated majority of data-bearing voting members in the replica set . In a 3-node replica set (Primary-Secondary-Secondary), this majority is 2. In a 5-node set, it's 3 . A node is considered data-bearing if it is not an arbiter. This ensures that the write is highly available and cannot be lost in a standard failover scenario.
The j: true option requests acknowledgment that the write operation has been written to the on-disk journal . When combined with w: "majority", this request applies to every member that contributes to the majority . Without j: true, a node might acknowledge the write as soon as it's in memory, leaving a window where a crash could result in data loss. With j: true, the acknowledgment is only sent after the journal flush, guaranteeing durability against a hard shutdown.
The replica set configuration setting writeConcernMajorityJournalDefault plays a critical role in how { w: "majority", j: true } behaves .
Therefore, when you explicitly set { w: "majority", j: true }, you are overriding any default behavior and demanding durable acknowledgment from the majority, regardless of how writeConcernMajorityJournalDefault is configured.
This strong consistency guarantee comes with a significant performance cost . j: true forces a disk flush operation, which is inherently slow. Additionally, w: "majority" requires waiting for network round-trips to other nodes. The latency of a write with this setting will be at least as high as the slowest of these operations across the majority of nodes. Consequently, this write concern is typically reserved for critical data where data loss is unacceptable.
It is best practice to combine this write concern with the wtimeout option . For example: { w: "majority", j: true, wtimeout: 5000 }. This prevents the client from blocking indefinitely if the required majority of nodes cannot be reached or are too slow to flush their journals. If the timeout is exceeded, the operation fails with a write concern error, but the write may still succeed on a subset of nodes .