レプリカセットの選挙
レプリカセットでは、どのセット ノードがプライマリになるかを決定するために選挙が使用されます。レプリカセットでは、次のようなさまざまなイベントに応じて選挙をトリガーできます。
レプリカセットへの新しいノードの追加
rs.stepDown()やrs.reconfig()などのメソッドを使用してレプリカセットのメンテナンスを実行セカンダリノードが、設定された
timeout（デフォルトでは 10 秒）よりも長時間にわたってプライマリへの接続を失った場合。
次の図では、プライマリ ノードが configured timeout よりも長時間使用できなくなり、 自動フェイルオーバー プロセスがトリガーされています。残りのセカンダリのうちの 1 つは、新しいプライマリを選択し、自動的に通常の操作を再開するよう求めます。
レプリカセットは、選挙が正常に完了するまで、書込み操作を処理できません。読み取りクエリがセカンダリで実行されるように構成されている場合、レプリカセットは引き続き読み取りクエリを処理できます。
デフォルトのreplica
configuration settingsを前提とすると、クラスターが新しいプライマリを選択するまでの時間の中央値は、通常12秒を超えないはずです。 これには、プライマリを利用不可としてマークし、 選挙を呼び出して完了するために必要な時間が含まれます。 settings.electionTimeoutMillisレプリケーション構成オプションを変更することで、この期間を調整できます。 ただし、ネットワーク レイテンシなどの要因により、レプリカセット選挙が完了するまでの時間が延長される可能性があり、それによりクラスターがプライマリなしで稼働する時間が影響を受けることがあります。 これらの要因は、お使いのクラスター アーキテクチャによって異なります。
アプリケーション接続ロジックには、自動フェールオーバーとその後の選挙に対する許容範囲が含まれている必要があります。MongoDB ドライバーはプライマリの損失を検出し、自動的に 1 回、特定の書き込み操作を再試行することで、自動フェイルオーバーと選挙の組み込み処理を追加で行います。
互換性のあるドライバでは、デフォルトで再試行可能な書き込みが有効になります
選挙に影響を与える要因と条件
レプリケーション選挙プロトコル
レプリケーション protocolVersion: 1 は、レプリカセットのフェイルオーバー時間を短縮し、複数のプライマリを同時に検出する時間を短縮します。
catchUpTimeoutMillisを使用すると、フェイルオーバーの迅速化と w:1 書込み（write）の保持のどちらを優先するかを設定できます。
pv1の詳細については、「自己管理型レプリカセットのプロトコル バージョン 」を参照してください。
ハートビート
レプリカセットのノードは、2 秒ごとにハートビート (ping) を相互に送信します。10 秒以内にハートビートが戻らない場合、その期限を過ぎたノードは他のノードからアクセス不可としてマークされます。
ノードの優先順位
レプリカセットのプライマリが安定した場合、選挙アルゴリズムによって、使用可能な priority が最も高いセカンダリが選挙を呼び出すよう「ベストエフォート」による試行が行われます。ノードの優先順位は、選挙のタイミングと結果の両方に影響します。優先順位の高いセカンダリノードは、優先順位の低いセカンダリノードよりも比較的早く選挙を呼び出し、勝つ可能性も高くなります。ただし、優先順位の高いセカンダリが使用できる場合でも、優先順位の低いインスタンスが短期間プライマリとして選ばれる場合があります。レプリカセットのノードは、優先順位が最も高いノードがプライマリになるまで、引き続き選挙を呼び出します。
優先順位が 0 のノードはプライマリになることができず、選挙に参加しません。詳細については、「優先度 0 のレプリカセット ノード」を参照してください。
ミラーリングされた読み取り
MongoDB は、選出可能なセカンダリ ノードのキャッシュを最も最近アクセスされたデータを使用して事前にウォームアップするために、ミラーリングされた読み取りを提供します。 ミラーリングされた読み取りでは、プライマリは受信した操作のサブセットをミラーリングし、選出可能なセカンダリのサブセットに送信できます。 セカンダリのキャッシュを事前にウォームアップしておくと、選出後のパフォーマンスをより迅速に復元できます。
詳細については、「ミラーリングされた読み取り」を参照してください。
データセンターの喪失
分散レプリカセットでは、あるデータセンターが失われると、他のデータセンターまたはデータセンターの残りのノードがプライマリを選出できなくなる可能性があります。
可能であれば、レプリカセットメンバーを複数のデータセンターに分散させ、データセンターが喪失した場合でも、残りのレプリカセットノードから新しいプライマリノードが選ばれる可能性を最大限に維持します。
ネットワークパーティション
ネットワークパーティションは、プライマリを少数のノードを含むパーティションに分離できます。プライマリがレプリカセット内の投票権のあるノードを少数しか認識できないことを検出すると、プライマリは降格してセカンダリになります。独立して、パーティション内の投票権のあるノードのmajority（自分自身を含む）と通信できるノードは、新しいプライマリになるための選挙を行います。
投票ノード
あるノードに選挙での投票権が与えられるかどうかは、レプリカセット ノードの構成設定members[n].votesとノードのstateによって決まります。
members[n].votes設定が選挙での 1 票に等しいすべてのレプリカセット ノード。ノードを選挙での投票から除外するにはmembers[n].votes構成の値を0に変更します。投票資格をのあるノードは、投票権があり下記の状態に該当するノードのみです。
投票権のないノード
投票権のないノードからは選挙での投票は実行されませんが、レプリカセットのデータのコピーを保持し、クライアント アプリケーションからの読み取り操作を受け入れることができます。
レプリカセットには最大 50 のノードを含めることができますが、投票権を持つノードの上限数は 7 つであるため、投票権を持たないノードであればレプリカセットには 7 つ以上のノードを含めることができます。
投票権のない（すなわち votes が 0 の）ノードの priority は 0 である必要があります。
たとえば、次の 9 ノードのレプリカセットには、投票ノードが 7 つ、投票権のないノードが 2 つ含まれます。
投票権のないノードでは、 votesとpriorityがいずれも0に等しくなります。
{ "_id" : <num>, "host" : <hostname:port>, "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 0, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 0 }
重要
どのノードがプライマリになるかを操作するために投票数を変更しないでください。代わりに、 members[n].priorityオプションを変更してください。例外的な場合のみ投票数を変更します。例えば 7 件を超えるノードを許可する場合などがあります。
投票権のないノードを設定するには、「 投票権のない自己管理型レプリカセット ノードの設定 」を参照してください。