Configuring Write Concerns
1. Setting Write Concern
| Form | Effect |
|---|---|
| {w, j, wtimeout} | Tuple |
| Per op | Pass in op options |
| Connection-string | w=majority&j=true&wtimeoutMS=5000 |
2. Using Acknowledged Writes
| w | Effect |
|---|---|
| 1 (default) | Primary ack |
| Errors | Returned to client |
3. Using Majority Writes
| Aspect | Detail |
|---|---|
| w: "majority" | Majority voting members must ack |
| Durability | Will survive failover |
| Default (5.0+) | w: majority for client writes |
4. Using Journaled Writes
| Option | Effect |
|---|---|
| j: true | Wait for journal commit (on-disk) |
| Default (4.4+) | j: true with w: "majority" |
5. Setting Write Timeout
| Option | Effect |
|---|---|
| wtimeout (ms) | Max wait for replication ack; 0 = infinite |
| Behavior | Write may still apply on primary even if timeout |
6. Using Unacknowledged Writes
| Setting | Effect |
|---|---|
| w: 0 | Fire-and-forget; no errors returned |
| Risk | Silent data loss |
7. Using Custom Write Concern
| Aspect | Detail |
|---|---|
| getLastErrorModes | Define in rs.conf().settings |
| Form | e.g. {multiDC: {region: 2}} |
| Use | Cross-region durability |
8. Understanding Write Concern Performance
| w | Latency |
|---|---|
| 0 | Lowest |
| 1 | Primary RTT |
| majority | Primary + slowest of majority |
| +j: true | Add fsync wait (~few ms) |
9. Configuring Default Write Concern
| Method | Detail |
|---|---|
| setDefaultRWConcern | Cluster-wide default |
| getDefaultRWConcern | Inspect current default |
db.adminCommand({ setDefaultRWConcern: 1, defaultWriteConcern: { w: "majority", j: true } });10. Handling Write Concern Errors
| Type | Detail |
|---|---|
| writeConcernError | Write succeeded on primary but replication failed/timed out |
| writeError | Operation itself failed |
| Mitigation | Idempotent design + retry |