/ /

書込み保証 (write concern)

書込み保証 (write concern) は、スタンドアロンのmongod、レプリカセット、またはクラスターへの書き込み (write) 操作に対してMongoDBから要求される確認応答のレベルを記述します。シャーディングされたクラスターでは、mongos インスタンスが書込み保証 (write concern)をシャードに渡します。

注意

マルチドキュメントトランザクションの場合、書込み保証 (write concern) は、トランザクションレベルで設定します。個々の操作レベルではありません。トランザクション内の個々の書込み (write) 操作について、書込み保証 (write concern) を明示的に設定しないでください。

レプリカセットとシャーディングされたクラスターは、グローバルなデフォルトの書込み保証 (write concern)をサポートしています。明示的な書込み保証 (write concern)のない操作は、グローバルなデフォルトのを継承します。デフォルトのグローバル書込み保証 (write concern)は過半数です。詳しくは、setDefaultRWConcern を参照してください。

MongoDB Atlas でホストされている配置の書込み保証 (write concern) の設定について詳しくは、「MongoDB Atlas での回復性の高いアプリケーションの構築」を参照してください。

書込み保証 (write concern) の仕様

書込み保証 (write concern) には以下のフィールドを含められます。

{ w: <value>, j: <boolean>, wtimeout: <number> }

w: Requests acknowledgment that the write operation has propagated to a specified number of mongod instances or to mongod instances with specified tags.
j: Requests acknowledgment that the write operation has been written to the on-disk journal.
wtimeout: Specifies a time limit to prevent write operations from blocking indefinitely.

`w` オプション

wオプションは、指定された数の mongod インスタンスまたは指定されたタグを持つ mongod インスタンスに、書込み (write) 操作が反映されたことの確認応答を要求します。書込み保証 (write concern) に w フィールドがない場合、MongoDB は w オプションをデフォルトの書込み保証 (write concern) に設定します。

注意

setDefaultRWConcern を使用してデフォルトの書込み保証 (write concern) を設定する場合は、w フィールド値を指定する必要があります。

w オプションは次の w: <value> 書込み保証をサポートしています。

値	説明
`"majority"`	Requests acknowledgment that the calculated majority of data-bearing voting members have durably written the change to their local oplog. The members then asynchronously apply changes as they read them from their local oplogs. レプリカセットのデータを保持する投票権を持つノードは、プライマリノードと、`members[n].votes` が `0` より大きいセカンダリノードです。詳細については、「{ w: "majority" } 書き込み後の読み取り」を参照してください。 `{ w: "majority" }` is the default write concern for most MongoDB deployments. See Implicit Default Write Concern. For example, consider a replica set with 3 voting members, Primary-Secondary-Secondary (P-S-S). For this replica set, the calculated majority is 2, and the write must propagate to the oplogs of the primary and one secondary to acknowledge the write concern to the client. Hidden, delayed, and priority 0 members with `members[n].votes` greater than `0` can acknowledge `"majority"` write operations. 遅延させたセカンダリは、設定された `secondaryDelaySecs` よりも早く書込み (write) 確認応答を返すことはありません。 If you specify a `"majority"` write concern for writes and the operation does not replicate to the calculated majority of replica set members before it returns a response, then the data eventually replicates or rolls back. See `wtimeout`. See Acknowledgment Behavior for when `mongod` instances acknowledge the write.
`<number>`	指定された数の `mongod` インスタンスに、書込み (write) 操作が反映されたことの確認応答を要求します。例を以下に示します。 `w: 1` スタンドアロン`mongod` またはレプリカセット内のプライマリに、書き込み (write)操作が反映されたことの確認応答を要求します。書き込み (write) 操作がいずれかのセカンダリに複製される前にプライマリが降格した場合、データはロールバックされる可能性があります。 WARNING: If write operations use `{ w: 1 }` write concern, the rollback directory may exclude writes submitted after an oplog hole if the primary restarts before the write operation completes. `w: 0` 書き込み (write)操作の確認応答を要求しません。ただし、`w: 0` はソケット例外やネットワークエラーに関する情報をアプリケーションに返す場合があります。書き込み (write) 操作がいずれかのセカンダリに複製される前にプライマリが降格した場合、データはロールバックされる可能性があります。 If you specify `w: 0` but include j: true, j: true prevails to request acknowledgment from the standalone `mongod` or the primary of a replica set. `w` 1より大きい場合は、プライマリと、指定された書込み保証 (write concern)を満たすために必要な数のデータを持つセカンダリからの確認応答が必要です。セカンダリは投票権を持つノードでなくても、書込み保証 (write concern) ) のしきい値を満たすことができます。例、プライマリと 2 セカンダリを含む 3 ノードのレプリカセットを考えてみましょう。`w: 2` を指定するには、プライマリと 1 つのセカンダリからの確認応答が必要です。`w: 3` を指定するには、プライマリと両方のセカンダリからの確認応答が必要です。 Hidden, delayed, and priority 0 members can acknowledge `w: <number>` write operations. 遅延させたセカンダリは、設定された `secondaryDelaySecs` よりも早く書込み (write) 確認応答を返すことはありません。 See Acknowledgment Behavior for when `mongod` instances acknowledge the write.
`<custom write concern name>`	`settings.getLastErrorModes` で定義されたカスタム書込み保証 (write concern) を満たす `tagged` ノードに、書込み (write) 操作が反映されたことの確認応答を要求します。例については、カスタムマルチデータセンター書込み保証 (write concern) を参照してください。カスタム書込み保証 (write concern)がプライマリからの確認応答のみを必要とし、書き込み (write) 操作がいずれかのセカンダリに複製される前にプライマリがステップダウンする場合は、データをロールバックできます。 See Acknowledgment Behavior for when `mongod` instances acknowledge the write.

Tip

`j` オプション

j オプションは、書込み (write) 操作がディスク上のジャーナルに書込まれたことを MongoDB に確認応答するよう要求します。

j

If j: true, requests acknowledgment that the mongod instances, as specified in the w: <value>, have written to the on-disk journal. j: true alone does not guarantee that the write will not roll back due to replica set primary failover.

With j: true, MongoDB returns only after the requested number of members, including the primary, have written to the journal. Previously j: true write concern in a replica set only requires the primary to write to the journal, regardless of the w: <value> write concern.

注意

ジャーナリングなしで実行中mongodインスタンスに j: true を含む書込み保証(書込み保証 (write concern)を指定すると、エラーが発生します。
If journaling is enabled, w: "majority" may imply j: true. The writeConcernMajorityJournalDefault replica set configuration setting determines the behavior. See Acknowledgment Behavior for details.
j: true を含む、または意味する書込み保証 (write concern) により、ジャーナルが即座に同期されます。「ジャーナリングプロセス」を参照してください。

`wtimeout`

このオプションは、プライマリで操作が成功した後に、書込み保証 (write concern)を実現するのに十分なノードに書き込み (write)操作が反映されるための時間制限をミリ秒単位で指定します。w が 1 以下の場合、wtimeout は適用されません。この時間制限内に書き込み操作が書込み保証 (write concern)を満たさない場合、 MongoDB は書込み保証 (write concern)エラーを返します。

wtimeout は、要求された書込み保証 (write concern) が最終的に成功した場合でも、指定された制限を超えると書込み (write) 操作が書込み保証 (write concern) エラーで返される原因となります。これらの書込み (write) 操作が戻るとき、MongoDB は書込み保証 (write concern) が wtimeout 時間制限を超える前に実行された正常なデータ変更を元に戻しません。

wtimeout オプションを指定せず、書込み保証 (write concern) レベルが達成できない場合、書込み (write) 操作は無期限にブロックされます。wtimeout に値 0 を指定することは、wtimeout オプションを使用しない書込み保証 (write concern) と同じです。

注意

プライマリ書込み操作に時間制限を設定するには、maxTimeMS() メソッドを使用します。

暗黙のデフォルト書込み保証 (write concern)

The implicit default write concern is w: majority. w: majority ensures write durability by requiring replica sets to wait for on-disk journaling by default, controlled by writeConcernMajorityJournalDefault. However, there is an edge case for replica set deployments containing arbiters:

レプリカセットの投票権の過半数は、投票ノードの半数に 1 を加え、端数を切り捨てた値です。データを保持する投票ノードの数が投票の過半数を超えない場合、デフォルトの書込み保証 (write concern) は{ w: 1 } になります。
その他のすべてのシナリオでは、デフォルトの書込み保証 (write concern) は{ w: "majority" }です。

具体的には、MongoDB では次の式を使用して、デフォルトの書込み保証 (write concern)を決定します。

if [ (#arbiters > 0) AND (#non-arbiters <= majority(#voting-nodes)) ]
    defaultWriteConcern = { w: 1 }
else
    defaultWriteConcern = { w: "majority" }

たとえば、次の配置とそれぞれのデフォルトの書込み保証 (write concern) について考えてみましょう。

Non-Arbiters	アービタ	投票ノード	投票ノードの過半数	暗黙のデフォルト書込み保証 (write concern)
2	1	3	2	`{ w: 1 }`
4	1	5	3	`{ w: "majority" }`

最初の例では、次のようになります。
- 投票ノードは合計 3 つあり、非アービタノードが 2 つ、アービタノードが 1 つです。
- 投票ノードの過半数（1 に 3 の半分を足し、切り捨てた値）は 2 です。
- 非アービタの数 (2) は、投票ノードの過半数 (2) と等しく、暗黙の書込み保証 (write concern) { w: 1 }になります。
2 番目の例では、次のようになります。
- 投票ノードは合計 5 つあり、非アービタノードが 4 つ、アービタノードが 1 つあります。
- 投票ノードの過半数（1 に 5 の半分を足し、切り捨てた値）は 3 です。
- 非アービタ数 (4) が投票ノードの過半数(3) よりも多いため、暗黙の書込み保証 (write concern)が { w: "majority" } になります。

On a sharded cluster, DDL (Data Definition Language) operations run with write concern "majority". If you specify a different write concern, the operation overrides the provided write concern with "majority".

確認応答動作

The w option and the j option determine when mongod instances acknowledge write operations.

スタンドアロン

スタンドアロンのmongod は、メモリへの書き込み (write) を適用した後、またはディスク上のジャーナルに書き込んだ後に書き込み (write)操作に確認応答を返します。次の表は、関連する書込み保証 (write concern) を持つスタンドアロンの確認応答動作を示しています。

	`j` が指定されていない	`j:true`	`j:false`
`w: 1`	インメモリ	On-disk journal	インメモリ
`w: "majority"`	ジャーナリングを使用している場合は、ディスク上のジャーナル	On-disk journal	インメモリ

注意

With writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. As such, "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.

レプリカセット

The w value determines the number of replica set members that must acknowledge the write before returning success. For each eligible member, the j option determines whether the member acknowledges writes after applying the write in memory or after writing to the on-disk journal.

w: "majority"

Any data-bearing voting member of the replica set can contribute to write acknowledgment of "majority" write operations.

次の表は、j の値に基づいてノードが書き込み (write) に確認通知を返せるタイミングを示しています。

`j` が指定されていない	確認応答は `writeConcernMajorityJournalDefault` の値によって異なります。 `true` の場合、確認応答にはMongoDB が書き込みを耐久性があるようにするためにディスク上のジャーナルに同期させる必要があり、これは `j: true` と同等です。 `writeConcernMajorityJournalDefault` のデフォルトは `true` `false` の場合、確認応答には `j: false` と同等のメモリへの書込み操作が必要です。
`j: true`	確認応答には、ディスク上のジャーナルに同期して書き込みを耐久性を持たせるためにMongoDBが必要です。
`j: false`	確認応答にはメモリへの書込み操作が必要です。通常、 `j: false`が設定されている場合は、ディスク上のジャーナルに操作を書き込む必要はありません。ただし、 `writeConcernMajorityJournalDefault: true`が設定されている場合は、 `j: false`が設定されていても操作をジャーナルに書き込む必要があります。 `j: false`と`writeConcernMajorityJournalDefault: true`が設定されている場合、書込み操作は非同期にジャーナルに書込まれます。 `w: majority`が設定されている書き込みは、ジャーナルがディスクにフラッシュされるまで完了したものとして確認されません。 `w: majority` 書込み（write）は、 `j`の設定に関係なく、 `"majority"`の読み取りスナップショットが完了するまで待機します。これは、 `writeConcernMajorityJournalDefault: true`が設定されている場合、読み取りスナップショットの過半数はジャーナリングされた書込みの過半数に基づいているためです。書込み操作がクライアントアプリケーションに`w: majority`確認応答を返すと、 `majority`読み取り保証（read concern）が設定されている場合、アプリケーションは書込みの結果を読み取ることができます。

For behavior details, see w: "majority" Behavior.

w: <number>

Any data-bearing member of the replica set can contribute to write acknowledgment of w: <number> write operations.

次の表は、j の値に基づいてノードが書き込み (write) に確認通知を返せるタイミングを示しています。

`j` が指定されていない	確認応答にはメモリへの書込み操作が必要で、`j: false` と同等です。
`j: true`	確認応答には、ディスク上のジャーナルに同期して書き込みを耐久性を持たせるためにMongoDBが必要です。
`j: false`	確認応答にはメモリへの書込み操作が必要です。

注意

Hidden, delayed, and priority 0 members can acknowledge w: <number> write operations.

遅延させたセカンダリは、設定された secondaryDelaySecs よりも早く書込み (write) 確認応答を返すことはありません。

{ w: "majority" } 書き込み後の読み取り

MongoDB 8.0 以降では、データを保持するノードの過半数がoplogエントリを永続的に書き込んだ後に、{ w: "majority" } 書き込み (write) は確認応答を返します。その後、ノードはローカル oplog から変更を読み取る際に変更を非同期に適用します。以前のリリースでは、 MongoDB は確認応答を返す前に、ノードが書き込み (write) を適用するまで待機していました。

{ w: "majority" }書き込み (write) 確認応答の直後のセカンダリに対するクエリは、セカンダリが書き込み (write) からの変更を適用する前に、コレクションから読み取る可能性があります。

アプリケーションがセカンダリから読み取り、{ w: "majority" } の書き込みからの変更にすぐにアクセスする必要がある場合は、これらの操作は因果的にコンシステントなセッションで実行します。

詳細情報

読み取り保証と書込み保証に関する推奨事項

プライマリで自分の書き込み (write)を読み取るには、"majority" 読み取り保証 (read concern) と { w: "majority" } 書込み保証 (write concern) を使用します。選挙中、以前のプライマリにルーティングされた読み取りは、新しいプライマリによって受け入れられた過半数によって確認された書き込み (write)を含まないスナップショットを返す可能性があります。

If you use a { w: n } write concern where n is greater than the calculated majority of the cluster's nodes and the cluster uses the default settings, enable the write concern "j" option to acknowledge the write to the journal. The "majority" read concern only allows you to read updates that are durable on a majority of nodes in the replica set.

注意

{ w: n }書込み保証 (write concern)で書込みを実行し、かつ n が計算された過半数より大きい場合、ジャーナリングなしでデフォルトのクラスター設定を使用すると、過半数のノードで書込みが耐久性があるになる前に書込み確認が行われることがあります。

因果関係がコンシステントなセッションと書込み保証 (write concern)

因果関係がコンシステントなクライアントセッションでは、次の場合にのみ因果整合性が保証されます。

関連する読み取り操作が "majority" 読み取り保証 (read concern)を使用し、かつ
the associated write operations use "majority" write concern.

詳細については、「因果整合性」を参照してください。

`w: "majority"` 動作

With writeConcernMajorityJournalDefault set to false, MongoDB does not wait for w: "majority" writes to be written to the on-disk journal before acknowledging the writes. As such, "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.
Hidden, delayed, and priority 0 members with members[n].votes greater than 0 can acknowledge "majority" write operations.
- 遅延させたセカンダリは、設定された secondaryDelaySecs よりも早く書込み (write) 確認応答を返すことはありません。
MongoDB 5.0 以降では、STARTUP2 状態のレプリカセットノードは書込み (write) の過半数に参加しません。

`local` データベースでは書込み保証 (write concern) はサポートされていません

ローカルデータベース、書込み保証 (write concern) がサポートされていません。MongoDB、ローカルデータベース内のコレクションに対する操作に対して設定された書込み保証 (write concern)は黙って無視されます。

書込み保証 (write concern) の過半数の計算

Tip

rs.status() は、過半数値を計算し、その結果を writeMajorityCount フィールドで返します。

The majority for write concern "majority" is calculated as the smaller of the following values:

アービタを含む投票権を持つ全ノードの過半数
データを持ち、投票権を持つ全ノードの数

警告

If the calculated majority equals the number of all data-bearing voting members, such as in a 3-member Primary-Secondary-Arbiter deployment, write concern "majority" may time out or never be acknowledged if a data-bearing voting member is down or unreachable. If possible, use a data-bearing voting member instead of an arbiter.

次の例について考えてみます。

投票権を持つ 3 つのノード、プライマリ-セカンダリ-セカンダリ（PSS）を持つレプリカセット
- 投票権を持つ全ノードの過半数は 2 です。
- データを保持し、投票権を持つ全ノードの数は 3 です。
The calculated majority is 2, the minimum of 2 and 3. The write must propagate to the primary and one of the secondaries to acknowledge the write concern "majority" to the client.
3 投票ノード、プライマリセカンダリアービタ（PSA）を持つレプリカセット
- 投票権を持つ全ノードの過半数は 2 です。
- データを保持し、投票権を持つノードの数は 2 です。
The calculated majority is 2, the minimum of 2 and 2. Since the write can only be applied to data-bearing members, the write must propagate to the primary and the secondary to acknowledge write concern "majority" to the client.

Tip
Avoid using "majority" write concern with P-S-A or other topologies that require all data-bearing voting members to be available to acknowledge writes. For the durability guarantees of a "majority" write concern, deploy a topology that does not require all data-bearing voting members to be available, such as P-S-S.

警告

レプリカセットに複数のアービタを配置しないでください。「複数のアービタに関する懸念事項」を参照してください。

既存のレプリカセットにアービタを追加するには、次のようにします。

通常、レプリカセットにデータを保持するノードが 2 つ以下の場合は、最初にクラスター全体の書込み保証 (write concern) をレプリカセットに設定しなければならない場合があります。
クラスター全体の書込み保証 (write concern) を設定する必要がある理由の詳細については、「クラスター全体の書込み保証 (write concern)」を参照してください。

アービタを使用して新しいレプリカセットを開始する前に、クラスター全体の書込み保証 (write concern) を変更する必要はありません。

Tip

デフォルトの書込み保証 (write concern) の公式

書込み保証 (write concern) の出所

MongoDB は、書込み保証（write concern）の provenance を追跡します。これは、特定の書込み保証（write concern）の来歴を示すものです。You may see provenance は、getLastError メトリクス、書込み保証（write concern）のエラーオブジェクト、MongoDB のログに表示されることがあります。

次の表は、可能な書込み保証 (write concern) provenance の値とその重要性を示しています。

出所	説明
`clientSupplied`	書き込み保証（write concern）がアプリケーションで指定されました。
`customDefault`	書込み保証 (write concern) は、カスタム定義されたデフォルト値に基づきます。`setDefaultRWConcern` を参照してください。
`getLastErrorDefaults`	書込み保証 (write concern) は、レプリカセットの `settings.getLastErrorDefaults` のフィールドに基づきます。
`implicitDefault`	他の書き込み保証（write concern）が一切指定されていない状態で、サーバーから発生した書き込み保証。

コミットクォーラムと対比した書込み保証 (write concern)

There are important differences between commit quorums and write concerns:

インデックス構築にはコミットクォーラムを使用します。
書き込み操作には書込み保証が必要です。

クラスタ内の各データ保有ノードは投票ノードです。

コミットクォーラムは、プライマリを含むデータを保持する投票ノードの数、またはどの投票ノードがインデックス構築を同時にコミットする準備ができている必要があるかを指定し、その後プライマリがコミットを実行します。

書き込み保証 (write concern) とは、指定された数のインスタンスに書き込み (write) が伝わったことを確認するレベルです。

バージョン8.0での変更：

コミットクォーラムでは、プライマリがインデックス構築にコミットする前に、インデックス構築を完了する準備が整っていなければならないノードの数を指定します。対照的に、プライマリがインデックス構築にコミットした時に、書き込み保証によって、コマンドが正常に返されるまでにインデックス構築の oplog エントリを複製する必要があるノードの数が指定されます。

以前のリリースでは、プライマリがインデックス構築にコミットした時に、書き込み保証によって、コマンドが正常に返されるまでにインデックス構築を完了する必要があるノードの数が指定されていました。

戻る

再試行可能な書き込み

ライフサイクル図