MongoDBのデフォルトの書き込みの懸念は、w:1です。 2012年のMongoDB2.2までさかのぼります。
現在のMongoDBバージョン（バージョン3.2.6以降）で書き込みの懸念を設定するために使用できる3つの異なる設定があります：
-
w設定 ：成功を宣言する前に書き込みを確認するノードの数。デフォルトは1で、プライマリノードの確認応答で十分であることを意味します。 -
j設定 ：確認する前に書き込みをジャーナルに記録する必要がありますか？デフォルトはwriteConcernMajorityJournalDefaultに依存します 。 - writeConcernMajorityJournalDefault
：
w:majorityを指定した場合jを設定せずに書き込みに関する書き込み懸念設定 、暗黙のjとは何ですか 価値？デフォルトはtrue（書き込みは、承認される前に、投票ノードの大部分でジャーナルに記録される必要があります。）
wtimeoutもあります 設定
書き込みが確認されていないことをクライアントに通知する前に、MongoDBが書き込みの懸念が満たされるまで待機する時間を構成します。そうしないと、書き込みの懸念が満たされるのを待っている書き込みは、失敗するのではなく、永遠に待つことができます。
ここでの特別な設定はw:majorityです。 。これは、書き込みが投票ノードの大部分に伝播する必要があることを意味します （そして彼らのジャーナルにも）承認されるレプリカセットで。これは、優れたパフォーマンスを提供しながら、間違いなく最も安全な設定です。理由は次のとおりです。
- 障害が発生した場合に、確認済みの書き込みがロールバックされるのを防ぎます。
- アプリケーションのスループットを調整して、レプリカセットが処理できる速度よりも速く書き込みを送信しないようにします（ハードウェアの制約、ネットワークの状況などによる）。
ご想像のとおり、投票ノードにはアービターが含まれます 。したがって、primary-secondary-arbiterが設定されたレプリカセットでは、w:majority 次のようなシナリオでは失敗する可能性があります：
- データ保持ノードの1つが何らかの理由でオフラインになっています。
- トポロジがprimary-arbiter-offlineになっているため、レプリカセットは書き込み可能なプライマリでオンラインのままです。
-
w:1で書き込みます 通常どおり成功しますが、これらの書き込みはロールバックされる可能性があります（投票データを含むノードの大部分に書き込まれなかったため）。 - アービターはデータを伝送しないため、
w:majorityアービターは投票ノードとしてカウントされるため、書き込みは失敗します（または無期限に待機します）。
このため、w:majorityを使用する場合は、アービターの使用はお勧めしません。 アプリケーションで。
チャンクの移動にはw:majorityが必要なため、シャードクラスターでシャードを形成する3ノードレプリカセットでアービターを使用することもお勧めしません。 。 1つのシャードでデータを含むノードに障害が発生すると、チャンクの移行操作に悪影響を及ぼします。