書込み保証 (write concern) は、スタンドアロンのmongod 、レプリカセット、またはシャーディングされたクラスターへの書込み(write) mongos操作に対してMongoDBから要求される確認応答のレベルを記述します。シャーディングされたクラスターでは、 インスタンスが書込み保証 (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: 指定された数の インスタンスまたは指定されたタグを持つ
mongodmongodインスタンスに、書込み (write)操作が反映されたことの確認応答を要求します。j: 書き込み （write ）操作がオンディスクのジャーナルに書き込まれたことの確認を要求します。
wtimeout: 書込み (write) 操作が無期限にブロックされないように時間制限を指定します。
w オプション
wオプションは、指定された数の mongod インスタンスまたは指定されたタグを持つ mongod インスタンスに、書込み (write) 操作が反映されたことの確認応答を要求します。書込み保証 (write concern) に w フィールドがない場合、MongoDB は w オプションをデフォルトの書込み保証 (write concern) に設定します。
注意
setDefaultRWConcern を使用してデフォルトの書込み保証 (write concern) を設定する場合は、w フィールド値を指定する必要があります。
w オプションは次の w: <value> 書込み保証をサポートしています。
値 | 説明 |
|---|---|
データを保持し投票権を持つノードの 計算された過半数が、ローカルoplogに変更を永続的に書込んだことの確認応答を要求します。その後、ノードはローカル oplog から変更を読み取る際に非同期に変更を適用します。 レプリカセットのデータを保持する投票権を持つノードは、プライマリノードと、 詳細については、「 {w: "過半数" } 書込み後の読み取り 」を参照してください。
例、3 投票メンバー、プライマリ-セカンダリ-セカンダリ（PSS）のレプリカセットを考えてみましょう。このレプリカセットにおける 計算上の過半数は2 であり、クライアントに対する書込み保証 (write concern)を認識するには、プライマリと 1 件のセカンダリの oplog に書込みを反映する必要があります。 が 0 遅延させたセカンダリは、設定された
インスタンスが書込み (write) | |
指定された数の
例、プライマリと 2 セカンダリを含む 3 ノードのレプリカセットを考えてみましょう。 非表示 ノード、 遅延 ノード、優先順位 ノードは、 書込み (write) 0 遅延させたセカンダリは、設定された インスタンスが書込み (write) | |
カスタム書込み保証 (write concern)がプライマリからの確認応答のみを必要とし、書込み (write) 操作がいずれかのセカンダリに複製される前にプライマリがステップダウンする場合は、データを ロールバック できます。 インスタンスが書込み (write) |
j オプション
j オプションは、書込み (write) 操作がディスク上のジャーナルに書込まれたことを MongoDB に確認応答するよう要求します。
|
注意
ジャーナリングなしで実行中 インスタンスに を含む書込み保証(書込み保証 (write
j: truemongodconcern)を指定すると、エラーが発生します。ジャーナリングが有効になっている場合、
w: "majority"はj: trueを意味する場合があります。writeConcernMajorityJournalDefaultレプリカセットの構成設定によって動作が決まります。詳細については、「確認動作」を参照してください。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)
暗黙のデフォルト書込み保証 (write concern)はw: majorityです。w: majority は、writeConcernMajorityJournalDefault によって制御されるデフォルトでディスク上のジャーナリングを待機するようレプリカセットに要求することで書き込み (write)耐久性を確保します。ただし、アービタを含むレプリカセットの配置ではエッジケースがあります。
レプリカセットの投票権の過半数は、投票ノードの半数に 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" }になります。
シャーディングされたクラスターでは、DDL（データ定義言語）操作は書込み保証"majority"で実行されます。別の書込み保証 (write concern) を指定すると、操作は指定された書込み保証 (write concern) を "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の場合、確認応答にはMongoDB が書込みを永続化するためにディスク上のジャーナルに同期する必要があり、これはj: trueと同等です。writeConcernMajorityJournalDefaultのデフォルトはtruefalseの場合、確認応答には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）が設定されている場合、アプリケーションは書込みの結果を読み取ることができます。
動作の詳細については、「
w: "majority"動作」を参照してください。w: <number>レプリカセットのデータを持つノードは、w: <number> 書込み (write) 操作の書込み確認ができます。
次の表は、j の値に基づいてノードが書込み (write) に確認通知を返せるタイミングを示しています。
jが指定されていない確認応答にはメモリへの書込み操作が必要で、
j: falseと同等です。j: true確認応答には、ディスク上のジャーナルに同期して書き込みを耐久性を持たせるためにMongoDBが必要です。
j: false確認応答にはメモリへの書込み操作が必要です。
注意
隠蔽ぺいされたノード、遅延ノード、優先順位 0 のノードは、w: <number> 書込み (write) 操作に確認通知を返せます。
遅延させたセカンダリは、設定された secondaryDelaySecs よりも早く書込み (write) 確認応答を返すことはありません。
{ w: "majority" } 書き込み後の読み取り
MongoDB 8.0 以降では、データを保持するノードの過半数がoplogエントリを永続的に書込んだ後に、{ w: "majority" } 書込み (write) は確認応答を返します。その後、ノードはローカル oplog から変更を読み取る際に変更を非同期に適用します。以前のリリースでは、 MongoDB は確認応答を返す前に、ノードが書込み (write) を適用するまで待機していました。
{ w: "majority" }書込み (write) 確認応答の直後のセカンダリに対するクエリは、セカンダリが書込み (write) からの変更を適用する前に、コレクションから読み取る可能性があります。
アプリケーションがセカンダリから読み取り、{ w: "majority" } の書き込みからの変更にすぐにアクセスする必要がある場合は、これらの操作は因果整合性のあるセッションで実行します。
詳細情報
読み取り保証と書込み保証に関する推奨事項
プライマリで独自の書込みを読み取るには、 読み取り保証 (read"majority" concern)と{ w: "majority" } 書込み保証 (write concern)を使用します。
ジャーナルへの書込みを確認するには、書込み保証（write 書込み保証 (write { w: n }concern)(n デフォルト 過半数 )を使用し、"majority" 読み取り保証 (read concern)では、レプリカセット内の過半数のノードで耐久性がある更新のみを読み取ることができます。
注意
{ w: n }書込み保証 (write concern)で書込みを実行し、かつ n が 計算された過半数より大きい場合、ジャーナリングなしでデフォルトのクラスター設定を使用すると、過半数のノードで書込みが永続的になる前に書込み確認が行われることがあります。
因果関係がコンシステントなセッションと書込み保証 (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) の過半数に参加しません。
local データベースでは書込み保証 (write 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 投票ノード、プライマリ セカンダリ アービタ（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
"majority"PSA またはデータを持つすべての投票メンバーに書込みの確認を求めるその他のトポロジーが含まれる場合は、"majority"書込み保証 (write concern)を使用しないでください。 書込み保証 (write concern)の耐久性保証には、PSS などのデータを持つすべての投票メンバーの確認を求めないトポロジーを配置します。
警告
レプリカセットに複数のアービタを配置しないでください。「複数のアービタに関する懸念事項」を参照してください。
既存のレプリカセットにアービタを追加するには、次のようにします。
通常、レプリカセットにデータを保持するノードが 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) が伝わったことを確認するレベルです。
バージョン 8.0 での変更: コミットクォーラムでは、プライマリがインデックス構築にコミットする前に、インデックス構築を完了する準備が整っていなければならないノードの数を指定します。対照的に、プライマリがインデックス構築にコミットした時に、書き込み保証によって、コマンドが正常に返されるまでにインデックス構築の oplog エントリを複製する必要があるノードの数が指定されます。
以前のリリースでは、プライマリがインデックス構築にコミットした時に、書き込み保証によって、コマンドが正常に返されるまでにインデックス構築を完了する必要があるノードの数が指定されていました。