書込み保証 (write concern)
書込み保証 (write concern) は、スタンドアロンの mongod、レプリカ セット、またはシャーディングされたクラスターへの書き込み操作に対して MongoDB から要求される確認応答のレベルを記述します。シャーディングされたクラスターでは、mongos インスタンスが書込み保証 (write concern) をシャードに渡します。
注意
マルチドキュメントトランザクションの場合、書込み保証 (write concern) は、トランザクションレベルで設定します。個々の操作レベルではありません。トランザクション内の個々の書込み (write) 操作について、書込み保証 (write concern) を明示的に設定しないでください。
マルチドキュメントトランザクションに対して "majority" 書込み保証を指定し、計算された レプリカセット ノードの過半数をトランザクションが複製できない場合、トランザクションがレプリカセット ノードに対してすぐにロールバックされない可能性があります。レプリカセットは 最終的に整合性が保たれます。トランザクションは常にすべてのレプリカセット ノードに適用またはロールバックされます。
レプリカセットとシャーディングされたクラスターは、グローバルなデフォルトの書込み保証（write concern）設定をサポートしています。明示的な書込み保証（write concern）を指定しない操作は、グローバルなデフォルトの書込み保証（write concern）設定を継承します。詳しくは setDefaultRWConcern を参照してください。
MongoDB Atlas でホストされている配置の書込み保証 (write concern) の設定について詳しくは、「 MongoDB Atlas での回復性の高いアプリケーションの構築」を参照してください。
書込み保証 (write concern) の仕様
書込み保証 (write concern) には以下のフィールドを含められます。
{ w: <value>, j: <boolean>, wtimeout: <number> }
wオプションは、指定された数の
mongodインスタンスまたは指定されたタグを持つmongodインスタンスに、書込み (write) 操作が反映されたことの確認応答を要求します。jオプションは書込み (write) 操作がオンディスクのジャーナルに書き込まれたことの確認を要求し、
wtimeoutオプションは 、書込み (write) 操作が無期限にブロックされるのを防ぐ時間制限を指定します。
w オプション
wオプションは、指定された数の mongod インスタンスまたは指定されたタグを持つ mongod インスタンスに、書込み (write) 操作が反映されたことの確認応答を要求します。書込み保証 (write concern) に w フィールドがない場合、MongoDB は w オプションをデフォルトの書込み保証 (write concern) に設定します。
注意
setDefaultRWConcern を使用してデフォルトの書込み保証 (write concern) を設定する場合は、w フィールド値を指定する必要があります。
w オプションを使用すると、次の w: <value> 書込み保証 (write concern) が利用できます。
値 | 説明 |
|---|---|
書込み 例、3 投票メンバー、プライマリ-セカンダリ-セカンダリ（PSS）のレプリカセットを考えてみましょう。このレプリカセットにおける 計算上の過半数は 2 であり、クライアント書込み保証 (write concern)を認識するには、プライマリと 1 件のセカンダリに書込みを反映する必要があります。 が 0 遅延させたセカンダリは、設定された 書込み (write)操作がクライアントに マルチドキュメントトランザクションに対して 書込み保証（ インスタンスが書込み (write) | |
指定された数の
たとえば、1 つのプライマリと 2 つのセカンダリを含む 3 つのノードからなるレプリカセットを考えてみます。 非表示 ノード、 遅延 ノード、優先順位 ノードは、 書込み (write) 0 遅延させたセカンダリは、設定された インスタンスが書込み (write) | |
カスタム書込み保証 (write concern) がプライマリからの確認応答のみを必要とし、書込み (write) 操作がいずれかのセカンダリに複製される前にプライマリがステップダウンする場合は、データをロールバックできます。 インスタンスが書込み (write) |
j オプション
j オプションは、書込み (write) 操作がディスク上のジャーナルに書込まれたことを MongoDB に確認応答するよう要求します。
|
注意
ジャーナリングなしで実行されている
mongodインスタンスにj: trueを含む書込み保証 (write concern) を指定すると、エラーが発生します。ジャーナリングが有効になっている場合、
w: "majority"はj: trueを意味する場合があります。writeConcernMajorityJournalDefaultレプリカセットの構成設定によって動作が決まります。詳細については、「確認動作」を参照してください。j: trueを含む、または意味する書込み保証 (write concern) により、ジャーナルが即座に同期されます。「ジャーナリング プロセス」を参照してください。
wtimeout
このオプションは、書込み保証 (write concern) の時間制限をミリ秒単位で指定します。wtimeout は w の値が 1 より大きい場合にのみ適用されます。
wtimeout は、要求された書込み保証 (write concern) が最終的に成功した場合でも、指定された制限を超えると書込み (write) 操作がエラーで返される原因となります。これらの書込み (write) 操作が戻るとき、MongoDB は書込み保証 (write concern)が wtimeout 時間制限を超える前に実行された正常なデータ変更を元に戻しません。
wtimeout オプションを指定せず、書込み保証 (write concern) レベルが達成できない場合、書込み (write) 操作は無期限にブロックされます。wtimeout に値 0 を指定することは、wtimeout オプションを使用しない書込み保証 (write concern) と同じです。
暗黙のデフォルト書込み保証 (write concern)
MongoDB 5.0以降では、暗黙のデフォルト書込み保証 は w: majority です。ただし、アービタを含む配置については、特別な考慮事項があります。
レプリカセットの投票権の過半数は、投票ノードの半数に 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 |
|
4 | 1 | 5 | 3 |
|
最初の例では、次のようになります。
投票ノードは合計 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" }になります。
確認応答動作
w オプションおよび j オプションは、mongod インスタンスが書込み (write) 操作を確認するタイミングを決定します。
スタンドアロン
スタンドアロンの mongod は、メモリへの書込み (write) を適用した後、またはディスク上のジャーナルに書込んだ後に、書込み (write) 操作に確認応答を返します。次の表は、スタンドアロンの確認応答動作と関連する書込み保証 (write concern) を示しています。
j が指定されていない | j:true | j:false | |
|---|---|---|---|
| インメモリ | On-disk journal | インメモリ |
| ジャーナリングを使用している場合は、ディスク上のジャーナル | On-disk journal | インメモリ |
注意
writeConcernMajorityJournalDefault を false に設定すると、MongoDB は書込み (write) を確認する前に、オンディスクのジャーナルに w: "majority" 書込み (write) が行われるのを待たなくなります。そのため、"majority" 書込み (write) 操作は、特定のレプリカセット内の大多数のノードでの一時的な損失（例: クラッシュおよび再起動）が発生したイベントにロールバックされる可能性があります。
レプリカセット
w に指定された値によって、成功を返す前に書込み (write) を確認しなければならないレプリカセット ノードの数が決まります。j オプションは適格なレプリカセット ノードごとに、ノードがメモリ内で書込み (write) 操作を適用した後、またはオンディスクのジャーナルに書き込んだ後に書込み (write) を確認するかどうかを決定します。
w: "majority"レプリカセットのデータを持つ投票ノードは、
"majority"書き込み (write) 操作の書き込み確認ができます。次の表は、j の値に基づいてノードが書込み (write) に確認通知を返せるタイミングを示しています。
jが指定されていない確認応答は
writeConcernMajorityJournalDefaultの値によって異なります。trueの場合、確認応答にはディスク上のジャーナル（j: true）への書込み操作が必要です。writeConcernMajorityJournalDefaultのデフォルトはtruefalseの場合、確認応答にはメモリ（j: false）への書込み操作が必要です。
j: true確認応答にはディスク上のジャーナルへの書込み操作が必要です。
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）が設定されている場合、アプリケーションは書込みの結果を読み取ることができます。
動作の詳細については、「
w: "majority"動作」を参照してください。w: <number>レプリカセットのデータを持つノードは、w: <number> 書込み (write) 操作の書込み確認ができます。
次の表は、j の値に基づいてノードが書込み (write) に確認通知を返せるタイミングを示しています。
jが指定されていない確認応答にはメモリ（
j: false）への書込み操作が必要です。j: true確認応答にはディスク上のジャーナルへの書込み操作が必要です。
j: false確認応答にはメモリへの書込み操作が必要です。
注意
隠蔽ぺいされたノード、遅延ノード、優先順位 0 のノードは、w: <number> 書込み (write) 操作に確認通知を返せます。
遅延させたセカンダリは、設定された secondaryDelaySecs よりも早く書込み (write) 確認応答を返すことはありません。
詳細情報
因果関係がコンシステントなセッションと書込み保証 (write concern)
因果関係がコンシステントなクライアント セッションでは、クライアント セッションは次の場合にのみ因果整合性を保証します。
関連する読み取り操作が
"majority"読み取り保証 (read concern)を使用し、かつ関連する書込み (write) 操作では
"majority"書込み保証 (write concern) が使用されます。
詳細については、「因果整合性」を参照してください。
w: "majority" 動作
writeConcernMajorityJournalDefaultをfalseに設定すると、MongoDB は書込み (write) を確認する前に、オンディスクのジャーナルにw: "majority"書込み (write) が行われるのを待たなくなります。そのため、"majority"書込み (write) 操作は、特定のレプリカセット内の大多数のノードでの一時的な損失（例: クラッシュおよび再起動）が発生したイベントにロールバックされる可能性があります。members[n].votesが0より大きい非表示ノード、遅延ノード、優先順位0ノードは、"majority"書き込み (write) 操作に確認応答を返せます。MongoDB 5.0 以降では、
STARTUP2状態のレプリカセット ノードは書込み (write) の過半数に参加しません。
データベースでは書込み保証 (writelocal concern) はサポートされていません
ローカル データベースでは、書込み保証 (write concern) がサポートされていません。MongoDBでは、ローカルデータベース内のコレクションに対する操作に対して設定された書込み保証 (write concern) は黙って無視されます。
書込み保証 (write concern) の過半数の計算
Tip
rs.status() は、過半数値を計算し、その結果を writeMajorityCount フィールドで返します。
書込み保証(write concern) "majority" の過半数は、次の値のうち小さい方として計算されます。
投票権を持つ全ノード（アービタを含む）の過半数対
データを持ち、投票権を持つ全ノードの数
警告
計算で導き出した過半数がすべてのデータを保持する投票ノードの数と等しい場合（3 ノードのプライマリ セカンダリ アービタ配置など）に、データを保持する投票ノードがダウンしているか到達不能のときは、書込み保証 (write concern) "majority" はタイムアウトするか、確認されないことがあります。可能であれば、アービタの代わりにデータを保持する投票ノードを使用します。
次の例について考えてみます。
投票権を持つ 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 つのノード、プライマリ-セカンダリ-アービタ（P-S-A）を持つレプリカセット
投票権を持つ全ノードの過半数は 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 the write concern"majority"to the client.Tip
(P-S-A) またはデータを持つすべての投票ノードに書込みの確認を求めるその他のトポロジーを含む
"majority"書込み保証は使用しないでください。"majority"書込み保証を使用した耐久性保証を希望するカスタマーは、データを持つすべての投票ノードの確認を求めないトポロジー（P-S-S など）を配置する必要があります。
警告
レプリカセットに複数のアービタを配置しないでください。「複数のアービタに関する懸念事項」を参照してください。
既存のレプリカセットにアービタを追加するには、次のようにします。
通常、レプリカセットにデータを保持するノードが 2 つ以下の場合は、最初にクラスター全体の書込み保証 (write concern) をレプリカセットに設定しなければならない場合があります。
クラスター全体の書込み保証 (write concern) を設定する必要がある理由の詳細については、「クラスター全体の書込み保証 (write concern)」を参照してください。
アービタを使用して新しいレプリカセットを開始する前に、クラスター全体の書込み保証 (write concern) を変更する必要はありません。
書込み保証 (write concern) の出所
MongoDB は、書込み保証（write concern）の provenance を追跡します。これは、特定の書込み保証（write concern）の来歴を示すものです。You may see provenance は、getLastError メトリクス、書込み保証（write concern）のエラー オブジェクト、MongoDB のログに表示されることがあります。
次の表は、可能な書込み保証 (write concern) provenance の値とその重要性を示しています。
出所 | 説明 |
|---|---|
| 書き込み保証（write concern）がアプリケーションで指定されました。 |
| 書込み保証 (write concern) は、カスタム定義されたデフォルト値に基づきます。 |
| 書込み保証 (write concern) は、レプリカセットの |
| 他の書き込み保証（write concern）が一切指定されていない状態で、サーバーから発生した書き込み保証。 |
コミットクォーラムと対比した書込み保証 (write concern)
コミットクォーラムと書込み保証 (write concern) には重要な違いがあります。
インデックス構築にはコミットクォーラムを使用します。
書き込み操作には書込み保証が必要です。
クラスタ内の各データ保有ノードは投票ノードです。
コミットクォーラムでは、データを保持する投票ノードの数、またはプライマリがコミットを実行する前にプライマリを含めてどの投票ノードが同時インデックス ビルドのコミット準備をしておく必要があるかを指定します。
書込み保証 (write concern) とは、指定された数のインスタンスに書込み (write) が伝わったことを確認するレベルです。
コミットクォーラムでは、プライマリがインデックス構築にコミットする前に、インデックス構築を完了する準備が整っていなければならないノードの数を指定します。対照的に、プライマリがインデックス構築にコミットした時に、書込み保証によって、コマンドが返されるまでにインデックス構築を完了する必要があるノードの数が指定されます。