Docs Menu
Docs Home
/
MongoDBマニュアル
/
CRUD 操作

書込み保証 (write concern)

項目一覧

  • 書込み保証 (write concern) の仕様
  • 暗黙のデフォルト書込み保証 (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) が利用できます。

値
説明
"majority"

データを保持し投票権を持つノードの 計算された過半数が、ローカルoplogに変更を永続的に書込んだことの確認応答を要求します。その後、ノードはローカル oplog から変更を読み取る際に非同期に変更を適用します。

バージョン 8.0 での変更: MongoDB は、以前のリリースのように、書き込み (write) を確認する前に、ノードが変更を適用するのを待ちません。

レプリカセットのデータを保持する投票権を持つノードは、プライマリノードと、members[n].votes が 0 より大きいセカンダリノードです。

詳細については、「 {w: "過半数" } 書込み後の読み取り 」を参照してください。

{ w: "majority" } は、 ほとんどのMongoDB配置におけるデフォルトの書込み保証 ( 書込み保証 (write concern) ) です。詳細については、「 暗黙のデフォルト書込み保証（write concern） 」を参照してください。

例、3 投票メンバー、プライマリ-セカンダリ-セカンダリ（PSS）のレプリカセットを考えてみましょう。このレプリカセットにおける 計算上の過半数は 2 であり、クライアント書込み保証 (write concern)保証を認識するには、プライマリと 1 件のセカンダリの oplog に書込みを反映する必要がありクライアント。

が 0members[n].votesより大きい 非表示 ノード、 遅延 ノード、優先順位0 "majority"ノードは、 書込み操作に確認応答を返せます。

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

書込み (write)操作がクライアントにw: "majority" 確認応答を返すと、クライアントは readConcern"majority" を使用して、その書込み (write) の結果を読み取ることができクライアント。

マルチドキュメントトランザクションに対して 書込み保証（"majority" 書込み保証 (write concern) ）を指定した場合に、レプリカセットの 計算された過半数へのレプリケート トランザクションに失敗すると、そのトランザクションはレプリカレプリカセットノードに対してすぐにロールバックされない可能性があります。レプリカセットは 結果整合性 が得られます。トランザクションは常にすべてのレプリカセットメンバーに適用またはロールバックされます。

インスタンスが書込み (write) mongodを確認する場合は Acknowledgment Behavior を参照してください。

<number>

指定された数の mongod インスタンスに、書込み (write) 操作が反映されたことの確認応答を要求します。例を以下に示します。

w: 1

スタンドアロン mongod またはレプリカセット内のプライマリに、書込み (write) 操作が反映されたことの確認応答を要求します。書込み (write) 操作がいずれかのセカンダリに複製される前にプライマリがダウンした場合、データはロールバックされる可能性があります。

警告: { w: 1 }書込み (write) 操作で 書込み保証 ( 書込み保証 (write concern) ) が使用される場合、書込み (write)操作が完了する前にプライマリが再起動すると、ロールバックディレクトリはoplog hole 後に送信された書込み (write) を除外することがあります。

w: 0

書込み (write) 操作の確認応答を要求しません。ただし、w: 0 はソケット例外やネットワーク エラーに関する情報をアプリケーションに返す場合があります。書込み (write) 操作がいずれかのセカンダリに複製される前にプライマリがダウンした場合、データはロールバックされる可能性があります。

w: 0を指定して j: true を含めると、スタンドアロン またはレプリカセットのプライマリからの確認リクエストよりも j: mongodtrue が優先されます。

w 1より大きい場合は、プライマリと、指定された書込み保証 (write concern) を満たすために必要な数のデータを持つセカンダリからの確認応答が必要です。セカンダリは投票権を持つノードでなくても、書込み保証 (write concern) のしきい値を満たすことができます。

たとえば、1 つのプライマリと 2 つのセカンダリを含む 3 つのノードからなるレプリカセットを考えてみます。w: 2 を指定すると、プライマリとセカンダリの 1 つからの確認応答が必要になります。w: 3 を指定すると、プライマリと両方のセカンダリからの確認応答が必要になります。

非表示 ノード、 遅延 ノード、優先順位 ノードは、 書込み (write) 0w: <number>操作に確認通知を返せます。

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

インスタンスが書込み (write) mongodを確認する場合は Acknowledgment Behavior を参照してください。

<custom write concern name>

settings.getLastErrorModes で定義されたカスタム書込み保証 (write concern) を満たす tagged ノードに、書込み (write) 操作が反映されたことの確認応答を要求します。例については、カスタム マルチデータセンター書込み保証 (write concern) を参照してください。

カスタム書込み保証 (write concern) がプライマリからの確認応答のみを必要とし、書込み (write) 操作がいずれかのセカンダリに複製される前にプライマリがステップダウンする場合は、データをロールバックできます。

インスタンスが書込み (write) mongodを確認する場合は Acknowledgment Behavior を参照してください。

Tip

以下も参照してください。

j オプション

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

j

j: trueの場合、mongod w: で指定された インスタンスがオンディスクのジャーナルに書き込んだことの確認を要求します。<value> 自体は、レプリカセットのプライマリフェイルオーバーにより書込みj: true (write) がロールバックされないことを保証するものではありません。

j: trueを使用すると、MongoDB は、要求された数のノード（プライマリを含む）がジャーナルに書込んだ後にのみ返します。 j: true以前は、レプリカセット内の 書込み保証 (write concern) では、 w: "value" <value>書込み保証 (write concern) に関係なく、 プライマリ のみがジャーナルに書込む必要がありました。

注意

  • ジャーナリングなしで実行されている 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

{ 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" } になります。

確認応答動作

w オプションおよび j オプションは、mongod インスタンスが書込み (write) 操作を確認するタイミングを決定します。

スタンドアロン

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

j が指定されていない
j:true
j:false

w: 1

インメモリ

On-disk journal

インメモリ

w: "majority"

ジャーナリングを使用している場合は、ディスク上のジャーナル

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 のデフォルトは true

  • false の場合、確認応答にはメモリ（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) 確認応答を返すことはありません。

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

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

{ w: "majority" } の書き込みが確認を返した直後のセカンダリに関するクエリは、セカンダリが書き込みからの変更を適用する前にコレクションから読み取ることができます。

アプリケーションがセカンダリから読み取り、{ w: "majority" } の書き込みで行われた変更にすぐにアクセスする必要がある場合は、因果関係が一貫したセッションでこれらの操作を実行してください。

詳細情報

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

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

  • 関連する読み取り操作が "majority" 読み取り保証 (read concern)を使用し、かつ

  • 関連する書込み (write) 操作では "majority" 書込み保証 (write concern) が使用されます。

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

w: "majority" 動作

データベースでは書込み保証 (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 など）を配置する必要があります。

警告

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

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

アービタを使用して新しいレプリカセットを開始する前に、クラスター全体の書込み保証 (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)

コミットクォーラムと書込み保証 (write concern) には重要な違いがあります。

  • インデックス構築にはコミットクォーラムを使用します。

  • 書き込み操作には書込み保証が必要です。

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

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

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

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

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

戻る

「スナップショット」

次へ

ライフサイクル図