Подтверждения записи и гарантированная устойчивость

A write concern tells MongoDB how many replica set members must acknowledge a write before the driver considers it successful. It is the primary knob for trading durability (more acknowledgements = safer) against latency (fewer acknowledgements = faster). Every write operation — insert, update, delete, or replace — can specify its own write concern.

The w field controls how many members must confirm the write. w: 0 means fire-and-forget (no acknowledgement at all). w: 1 (default) means only the primary must confirm. w: 2 means the primary plus one secondary. w: 'majority' is the recommended production setting — it waits for a majority of voting members to confirm.

w: 'majority' guarantees that the write has been replicated to a majority of voting members before the driver receives a success response. This means a newly elected primary will always have seen the write — even after a failover. It is the only setting that prevents data rollback on primary failure.

The j (journal) option controls whether MongoDB waits for the write to be committed to the on-disk journal before acknowledging. With j: true, even a server crash immediately after acknowledgement cannot lose the write. Without journaling (j: false), a crash between the in-memory write and the next journal flush could lose the operation.

wtimeout sets the maximum time (in milliseconds) the server waits for the required w acknowledgements. If the threshold is not met in time, MongoDB returns a WriteConcernError — but the write still happened on the primary. A timeout signals replication lag, not a write failure.

w: 0 sends the write and returns immediately without waiting for any acknowledgement. This maximises throughput for high-volume, loss-tolerant workloads like telemetry, analytics events, or log ingestion where occasional loss is acceptable. Never use it for financial transactions, user-generated content, or any data you cannot afford to lose.

When a primary fails and a secondary becomes primary, any writes the old primary had not yet replicated to a majority are rolled back. Those rolled-back writes are saved to a rollback folder on disk for manual recovery. Using w: 'majority' eliminates this risk because the write is only acknowledged after the majority has it.

In multi-document transactions, the write concern applies at the commit step, not on individual operations inside the transaction. Committing with w: 'majority' ensures all of the transaction's writes are durable on a majority before the application proceeds. Individual operation-level write concerns inside a transaction are ignored.

Since MongoDB 5.0, the implicit default write concern is w: 'majority' for replica sets and sharded clusters. Before 5.0, it defaulted to w: 1. This means that modern MongoDB deployments are safe by default, but you should still explicitly set write concerns in critical application code for clarity and portability.

Write concern can be set at three levels: operation level (per insert/update), collection level (when getting a collection handle), or client/connection string level. More specific levels override broader ones. Setting it at the client level applies to all operations by default, while operation-level settings are best for cases that need special durability guarantees.

Pick your write concern based on data criticality. Financial/transactional data: w: 'majority', j: true. User content: w: 'majority'. Session/cache data: w: 1. High-volume telemetry: w: 0. The right choice balances the cost of losing data versus the latency penalty of waiting for additional acknowledgements.

Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.

In this lesson you learned: write concern w controls how many members must acknowledge a write, w: 'majority' is the recommended production setting that prevents rollback after failover, and j: true adds on-disk journal durability for crash safety. Next up we explore read preferences and how to distribute read load across the replica set.