MongoDBの「書き込みの懸念」は、そこから期待できる書き込み確認のレベルを表します。書き込み操作で覚えておくことがかなり重要な設定であり、その動作は、特に分散MongoDBデプロイメント（レプリカセットやシャードクラスター）で理解するのに役立ちます。この投稿では、MongoDBの書き込みに関する懸念事項を使用する際の3つの落とし穴について説明します。
MongoDB書き込みの懸念
MongoDBのドキュメントでは、書き込みの懸念を「スタンドアロンのmongod、レプリカセット、またはシャーディングされたクラスターへの書き込み操作に対してMongoDBから要求される確認応答のレベル」と定義しています。 「
簡単に言えば、書き込みの懸念は、MongoDBへの書き込み操作とともに渡される「耐久性」の指標です。明確にするために、構文を見てみましょう：
{ w: <value>, j: <boolean>, wtimeout: <number> }
Where*,
w can be an integer | "majority" | , it represents the number of members that must acknowledge the write. Default value is 1.
j Requests that a write be acknowledged after it is written to the on-disk journal as opposed to just the system memory. Unspecified by default.
wtimeout specifies timeout for the applying the write concern. Unspecified by default. *詳細な構文は、WriteConcernSpecificationのドキュメントに記載されています。
* MongoDBブログの「耐久性と書き込みの安全性について」で、一般的な書き込みの懸念値に使用できるさまざまな「タグ」について詳しく学んでください。
例：
db.inventory.insert(
{ sku: "abcdxyz", qty : 100, category: "Clothing" },
{ writeConcern: { w: 2, j: true, wtimeout: 5000 } }
) 上記の挿入物の書き込みに関する懸念事項は、次のように読み取ることができます。レプリカセットの少なくとも2つのメンバーが5000ミリ秒以内にジャーナルに書き込んだ場合、またはエラーを返した場合に、この書き込みを確認します。 '。オプションの書き込み懸念値は過半数でした。つまり、「書き込み操作がプライマリを含む投票ノードの大部分に伝播したことを確認する必要があります。 「
#MongoDB書き込みの懸念-3つの知っておくべき警告クリックしてツイート書き込みの懸念の重要性は明らかです。 wの値を増やすと、書き込みの待ち時間が長くなり、失われる可能性も低くなります。書き込みに関する正しい値の選択は、実行される書き込みの遅延と耐久性の要件によって異なります。
これを書き込みの懸念事項の背景として、書き込みの懸念事項を使用する際に覚えておくべき3つの注意事項に移りましょう。
警告1：wtimeoutのないレプリカセットに書き込みの懸念を設定すると、書き込みが無期限にブロックされる可能性があります
上記の過半数の定義（MongoDB 3.0以降に適用可能）は、「投票ノード」の過半数から承認が要求されることを示しています。 「wtimeoutを指定しない場合 オプションであり、書き込みの懸念のレベルが達成できない場合、書き込み操作は無期限にブロックされます。 「
これにより、予期しない結果が生じる可能性があります。たとえば、2 + 1レプリカセット（プライマリ、セカンダリ、アービター）を検討します。唯一のリードレプリカがダウンした場合、「マジョリティ」オプションの書き込み懸念があるすべての書き込みは無期限にブロックされます。 wオプションが2に設定されている場合も同じことが起こります。別の極端な例は、3 + 2レプリカセットの場合です（プライマリ、2セカンダリおよび2アービター、推奨される構成ではありません）。マジョリティ番号（この場合は3）が3であるため、単一のデータノードが使用できない場合でも、すべての「マジョリティ」書き込みはブロックされます。
この問題を軽減する最も簡単な方法は、常にwtimeout値を指定して、書き込みの懸念を強制できない場合にクエリがタイムアウトできるようにすることです。ただし、このようなタイムアウトエラーが発生した場合、MongoDBは、タイムアウトが発生する前に一部のメンバーに対して行われた、すでに成功した書き込みを元に戻しません。
現在、書き込みが現在到達可能なノードの大部分に確実に到達するようにする設定もありません。したがって、必要なトポロジに基づいて書き込み懸念の値を設定することに注意してください。耐久性と可用性。
警告2：w：多数決でもデータが失われる可能性があります
投票メンバーの大多数が書き込みを承認すると、その耐久性が保証されるのは直感的に思えます。ただし、そうではありません。 jオプションが指定されていない場合、書き込みはメモリに書き込まれた直後に確認応答されることに注意してください。
したがって、異常な停電により、書き込みが伝播されたノードの大部分が削除された場合（syncPeriodSecsの前、つまりフラッシュされる前）、このような書き込みが失われる可能性があります。ディスク）。
書き込みの耐久性を確保するために、データベースのジャーナル処理をオフにせず、jオプションをtrueに設定することをお勧めします。実際、MongoDB 3.6以降、-nojournal WiredTigerストレージエンジンを使用するレプリカセットメンバーのフラグは非推奨になりました。
レプリカセットでw値が「majority」でjオプションが指定されていない場合、正確な耐久性の動作は、レプリカセット構成writeConcernMajorityJournalDefaultの値によって異なります。 trueに設定すると（およびジャーナリングが有効になっている場合）、投票メンバーの過半数のジャーナルに書き込まれた後、書き込みを確認します。
脇：ジャーナリングをオンにしても、commitIntervalMsの期間内に停止が発生すると、MMAPv1ストレージエンジンで書き込みが失われる可能性があります。一方、WiredTigerストレージエンジンは、jオプションがtrueに設定された書き込みを受信すると、ジャーナルファイルの同期を強制します。また、jがfalseに設定されている場合でも、最新のWiredTigerベースのデプロイメントへの確認済みの「大部分」の書き込みは、データノードの大部分が同時にクラッシュした場合にのみ失われる可能性があります。
警告3：w：0、j：trueを設定しても書き込みパフォーマンスは向上しません
これは、一度考えれば推論するのは簡単ですが、忘れるのも同様に簡単です。 wオプションを0に設定することは、通常、「ファイアアンドフォーゲット」方式でデータベースに書き込むために行われます。データベースインフラストラクチャにかなりの自信があり、すべての書き込みの耐久性よりもレイテンシを重視する場合です。ただし、jオプションをtrueに設定すると、データベースが戻る前にディスク上のジャーナルに書き込みが書き込まれるようにするため、wオプションは事実上オーバーライドされます。
書き込み操作の成功を保証するために書き込みの懸念事項を使用している場合は、これら3つの重要な注意事項を忘れないでください。ご不明な点がございましたら、Twitterまたはメールでお気軽にお問い合わせください。
