優先順位 0 のレプリカセット ノード
priority 0{3 メンバーは プライマリ になること ができずtrigger 、 選挙 を でき ないメンバーです。優先順位0メンバーは、 w : <number>の書込み保証 ( write concern ) で発行された書込み (write) 操作に確認応答を返せます。 "majority"書込み保証（write concern）の場合、優先順位0ノードは投票ノードでもある必要があります（ members[n].votesが0より大きい場合）、書込みを確認します。 投票権のないレプリカセット ノード（ members[n].votesは0です）は、 "majority"書込み保証（write concern）付きで書込み操作の確認に貢献できません。
前述の制限を除き、 priority 0を持つセカンダリは通常のセカンダリとして機能します。つまり、データセットのコピーを保持し、読み取り操作を受け入れ、選挙に投票します。
レプリカセット ノードをpriority 0で構成すると、特定のノードがメインの配置から離れたデータセンターに配置され、レイテンシが高くなります。 ローカルの読み取りリクエストには十分対応できますが、レイテンシがあるため、プライマリのタスクを実行するための理想的な候補ではない可能性があります。
この状況では、次の図は、プライマリとセカンダリをホストする左側のデータセンターと、プライマリにならないように優先順位を0に設定されたセカンダリをホストする右側のデータセンターを示しています。 この設定により、左側のデータセンターのメンバーのみが選挙でプライマリになる資格があります。
これをレプリカセット ノードのデフォルトの優先順位priority 1と比較します。このシナリオではいずれかのセカンダリがプライマリとして機能する資格があります。 詳しくは、「 2 つ以上のデータセンターに分散されたレプリカセット」を参照してください。
スタンバイとしての優先順位 0 のメンバー
priority 0のセカンダリはスタンバイとして機能できます。 一部のレプリカセットでは、妥当な時間内に新しいノードを追加できない場合があります。 スタンバイ メンバーは、使用できないメンバーを置き換えるために、データの現在のコピーを保持します。
多くの場合、 スタンバイ を優先順位 0に設定する必要はありません。ただし、さまざまなハードウェアまたは地理的分散を持つレプリカセットでは、優先順位 0のスタンバイでは、特定のノードのみがプライマリになります。
優先順位0 は、スタンバイハードウェアまたはワークロードプロファイルが異なるセットのノードによっても価値がある場合があります。このような場合は、プライマリにならないように、優先順位 0のノードを配置します。この目的では、非表示メンバーを使用することも検討してください。
セットにすでに 7 つの投票ノードがある場合は、非投票ノード として設定します。
フェイルオーバーに関する考慮事項
priority 0を使用するようにセカンダリを構成する場合は、可能性のあるすべてのネットワーク パーティションを含む、潜在的なフェイルオーバー パターンを考慮してください。 常にメインのデータセンターに、投票メンバーとプライマリになる資格のあるメンバーの両方が含まれていることを確認してください。
例
priority 0を持つようにセカンダリを構成するには、「自己管理型セカンダリがプライマリにならないようにする 」を参照してください。