2台のマシンのみのレプリカセットは意味がありますか？

Question

多くのMongoDBチュートリアルでは、レプリカセットについて説明するときに、2つのマシンの例を示しています。1つは最初にプライマリとして初期化され、もう1つは最初はセカンダリとして作成されています。

私が理解しているように：

プライマリメンバーが予期せず終了した場合でも、過半数（2台のマシンのレプリカセットでは2つ）がないため、セカンダリメンバーは新しいプライマリを選出しません。
_read_preference=ReadPreference.SECONDARY_を使用しても、プライマリメンバーが利用できない場合、データベースからデータを読み取ることはできません。
プライマリメンバーを再作成しても機能しません。プライマリメンバーがないため、既存のレプリカセットに追加できません。異なるIDで異なるレプリカセットを作成するため、rs.initiate();もできません。

したがって、レプリカセットにメンバーが2つしかないという現実的な状況はありますか？または、そのような状況は理論上のものにすぎず、実際にはすべてのレプリカセットに少なくとも3つのメンバーが存在すると予想されますか？

Stennie · Accepted Answer

プライマリメンバーが予期せず終了した場合でも、過半数（2台のマシンのレプリカセットでは2台）がないため、セカンダリメンバーは新しいプライマリを選択しません。

これは正しいです。予備選挙を選出（および維持）するには、過半数の投票メンバーが利用可能である必要があります。

Read_preference = ReadPreference.SECONDARYを使用しても、プライマリメンバーが利用できない場合、データベースからデータを読み取ることはできません。

これは誤りです。プライマリがないと、レプリカセットに書き込むことはできませんが、secondary、primaryPreferred、secondaryPreferred、nearestなどの非プライマリ読み取り設定を使用すると、読み取りは引き続き可能です。デフォルトの読み取り設定はprimaryであり、強い整合性を提供します（セカンダリから読み取るときの最終的な整合性に対して）。 primaryPreferred読み取り設定は、可能な場合はプライマリから読み取り、それ以外の場合はセカンダリから読み取ります。

プライマリメンバーを再作成しても機能しません。プライマリメンバーがないため、既存のレプリカセットに追加できません。 rs.initiate（）;異なるIDで異なるレプリカセットを作成するためです。

2ノードレプリカセットのメンバーの1つを失った場合、強制再構成存続メンバーを単一ノードレプリカセットにしてから、新しいメンバーを追加できます。 rs.initiate()を実行する必要があるのは、レプリカセットの有効期間中に1回だけです。

したがって、レプリカセットに2つのメンバーのみが存在することは意味があるという現実の状況はありますか？または、そのような状況は単なる理論上のものであり、実際にはすべてのレプリカセットに少なくとも3つのメンバーが存在すると予想されるでしょうか。

一般に、ほとんどのレプリカセットのデプロイメントには、自動フェイルオーバーを可能にするのに十分なメンバーがあります（つまり、最低3つのメンバー）。高可用性が問題にならない場合（または手動による介入が必要な場合）、2つのメンバーのレプリカセットは許可されません。ただし、フェイルオーバーを許可するためのより一般的なオプションは、3番目の voting-only member（akaarbiter）を追加することですレプリカセット。

アービターは、2つのデータを保持するメンバーの1つが3メンバー構成で使用できない場合に過半数に必要な追加投票を提供する軽量の投票専用メンバーです。アービターは可用性に役立ちますが、3番目のデータ保持メンバーに対する妥協です。アービターを備えた3つのメンバーのレプリカセットが機能低下状態にある場合（つまり、データを保持するメンバーの1つが利用できない場合）、プライマリは存在しますが、データの冗長性やレプリケーションはなくなります。アービターは、アプリケーションが majority書き込みの懸念に依存してデータがレプリカセットメンバーの大部分に確実にコミットされることを防止します。

私の個人的な推奨事項は、本番レプリカセットの最小として3つのデータベアリングメンバーを展開することですが、開発または重要でないデプロイメントでは、データベアリングメンバーの数を減らすことができます。

Vince Bowdren · Answer

2メンバーのレプリカセットを使用すると、手動でフェイルオーバーできるため、何もしないよりはましです。ただし、自動フェイルオーバーほど優れていません。

2メンバーのレプリカセットがある場合、ノードの1つがダウンした場合、couldで手動フェイルオーバーを実行します。レプリカセットを強制的に再構成して、残りのノードが1つだけのメンバーになるようにする必要があります。クライアントアプリケーションする必要がありますこの新しい構成でレプリカセットに引き続きアクセスできます。

これはフェイルオーバーオプションを提供しますが、欠点があります：

最初のノード障害に気付くまで、および再構成を行うまでに時間がかかります。それは高額なダウンタイムになる可能性があります。
残りのレプリカセットは堅牢ではなく、単一のメンバーしかありません。

比較すると、軽量のアービターを3番目のノードとしてほとんど費用をかけずに追加できます。これにより、ノードがダウンしたときに自動（高速）フェイルオーバーが提供されます。