書き込み確認と耐久性の保証
w:majority、w:1、ジャーナリングのオプションを設定し、書き込み操作の耐久性保証を調整します。
「書き込み確認と耐久性の保証」はCoddyKit上の無料MongoDB Academyレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはMongoDB Academy学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 MongoDB Academyコースには全4レッスンが含まれています。
このレッスンの一部はまだ翻訳されておらず、英語で表示されています。
What Is a Write Concern?
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 Option: Counting Acknowledgements
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:1 — only primary acknowledges (default)
db.orders.insertOne({ item: 'pen' }, { writeConcern: { w: 1 } })
// w:majority — safe for production
db.orders.insertOne({ item: 'pen' }, { writeConcern: { w: 'majority' } })w: majority — The Recommended Setting
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.
// Set default write concern at the database level
db.runCommand({
setDefaultRWConcern: 1,
defaultWriteConcern: { w: 'majority', wtimeout: 5000 }
})The j Option: Journal Durability
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.
// Fully durable write: majority replication + journaled
db.payments.insertOne(
{ amount: 499.99, currency: 'USD' },
{ writeConcern: { w: 'majority', j: true, wtimeout: 5000 } }
)The wtimeout Option
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.
// Timeout after 3 seconds if secondaries are slow
db.logs.insertOne(
{ event: 'login', userId: 'u123' },
{ writeConcern: { w: 'majority', wtimeout: 3000 } }
)w:0 Fire-and-Forget: When to Use It
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.
// High-throughput metrics logging — loss acceptable
await db.collection('metrics').insertMany(
readings,
{ writeConcern: { w: 0 } }
)Write Concern and Rollback
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.
Combining Write Concern With Transactions
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.
const session = client.startSession()
await session.withTransaction(async () => {
await orders.insertOne({ item: 'book' }, { session })
await inventory.updateOne({ _id: 1 }, { $inc: { qty: -1 } }, { session })
}, { writeConcern: { w: 'majority' } })Default Write Concern in MongoDB 5+
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.
// Verify the current default write concern
db.adminCommand({ getDefaultRWConcern: 1 })
// { defaultWriteConcern: { w: 'majority' }, ... }Write Concern at the Client Level
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.
// Set write concern at MongoClient level
const client = new MongoClient(uri, {
writeConcern: { w: 'majority', j: true, wtimeout: 5000 }
})
// Override per-operation when needed
await db.criticalData.insertOne(doc, { writeConcern: { w: 3 } })Choosing the Right Write Concern
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.
Quick Check
Test your understanding of MongoDB & NoSQL Databases concepts from this lesson.
Lesson Recap
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.
よくある質問
「書き込み確認と耐久性の保証」レッスンは無料ですか？
はい。「書き込み確認と耐久性の保証」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、MongoDB Academyコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 MongoDB Academyコースには全4レッスンが含まれています。
「書き込み確認と耐久性の保証」で何を学びますか？
w:majority、w:1、ジャーナリングのオプションを設定し、書き込み操作の耐久性保証を調整します。 ブラウザで直接実行するハンズオンコードでMongoDB Academyを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
MongoDB Academyを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのMongoDB Academyは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。
「書き込み確認と耐久性の保証」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このMongoDB Academyレッスンでコードを書いて実行できますか？
はい。すべてのMongoDB Academyレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。