レプリカセット アービタ
状況によっては（プライマリとセカンダリがあるが、コストの制約により別のセカンダリを追加できない場合など）、レプリカセットへのアービタ追加を選択できます。アービタはプライマリの選挙に参加しますが、アービタにはデータセットのコピーがないため、プライマリになることはできません。
アービタは厳密に1票の投票権があります。デフォルトでは、アービタの優先順位は0です。
重要
replica setのプライマリ メンバーまたはセカンダリ メンバーもホストするシステムでは、アービターを実行しないでください。
警告
シャードクラスターのシャードにプライマリ・セカンダリー・アービター（PSA）アーキテクチャを使用すると、データを含むセカンダリが利用できなくなると可用性が失われる可能性があります。 PSAクラスターは通常のレプリカセットとは異なります。シャードクラスターでは、操作の確認に必要な残りのクラスターメンバーにアービタがあると完了できない w: majority 書き込み保証 (write concern) 操作がシャードによって実行されます。
アービタを追加するには、「自己管理型レプリカセットへのアービタの追加 」を参照してください。
リリース バージョンに関する考慮事項
アービタは季刊 Rapid Releaseではサポートされません。配置にアービタが含まれている場合は、 LTSリリースのみを使用してください。
PSA レプリカセットのパフォーマンスの問題
3 ノードのプライマリセカンダリアービタ（PSA）アーキテクチャを使用している場合は、次の点を考慮してください。
セカンダリが使用できなくなったり遅延が発生したりすると、 書込み保証 (write concern
"majority"によってパフォーマンスの問題が発生することがあります。 こうした問題を軽減するためのアドバイスについては、「自己管理型 PSA レプリカセットのパフォーマンスの問題の軽減 」を参照してください。グローバル デフォルト
"majority"を使用しており、書込み保証 (write concern) が過半数のサイズより小さい場合、クエリは古い（完全には複製されていない）データを返すことがあります。
シャードキー、トランザクション、アービタ
レプリカセットにアービタがある場合、トランザクションを使用してシャードキーを変更することはできません。 アービタは、 マルチシャード トランザクションに必要なデータ操作に参加することはできません。
書込み操作が複数のシャードにまたがるトランザクションで、アービタを含むシャードを対象に読み取りまたは書込み操作が実行される場合、そのトランザクションはエラーとなり中止します。
複数のアービタに関する懸念
データの整合性に関する問題を回避するには、単一のアービタを使用します。複数のアービタにより、majority 書き込み保証（write concern）の確実な使用が妨げられます。
プライマリ ノードで障害が発生しても書き込みを継続するには、書き込み保証（write concern）の大半が、書き込み操作を確認する大多数のノードを必要とします。アービタはデータをストアしませんが、レプリカセット内のノード数に寄与します。レプリカセットに複数のアービタがある場合、ノード障害後にデータを持つノードの過半数が利用できる可能性は低くなります。
警告
セカンダリ ノードがプライマリ ノードより遅れており、クラスターが reconfigured の場合、複数のアービタからの投票により、遅れたノードが選出されます。古い構成で書き込みの過半数がコミットされていたとしても、新しいプライマリには、レプリケートされていない書き込みは行われません。その結果、データが失われます。
このシナリオを回避するには、最大で 1 つのアービタを使用します。
バージョン 5.3 で追加。
MongoDB 5.3 以降では、レプリカセット内の複数のアービタのサポートはデフォルトで無効になっています。レプリカセットに複数のアービターを追加しようとすると、サーバーはエラーを返します。
MongoServerError: Multiple arbiters are not allowed unless all nodes were started with --setParameter 'allowMultipleArbiters=true'
MongoDB 5.3 以降を使用してレプリカセットに複数のアービタを追加するには、allowMultipleArbiters パラメーターを true に設定して各ノードを起動します。
mongod --setParameter allowMultipleArbiters=true
セキュリティ
認証
authorization で実行する場合、アービタは認証のためにセットの他のノードと認証情報を交換します。MongoDB は認証プロセスを暗号化し、MongoDB 認証交換は暗号化されているため安全です。
アービタはデータを保存しないため、認証に使用されるユーザーとロールのマッピングの内部テーブルを保持しません。したがって、認証が有効になっているアービタにログオンする唯一の方法は、localhost 例外を使用することです。
通信
アービタと他のセット ノードとの通信は、選挙中の投票、ハートビート、構成データだけです。これらの交換は暗号化されません。
ただし、MongoDB 配置で TLS/SSL を使用する場合、MongoDB はレプリカセット ノード間のすべての通信を暗号化します。詳細については、「mongod および mongos を TLS/SSL 用に構成」を参照してください。
すべての MongoDB コンポーネントと同様に、アービタは信頼できるネットワーク環境で実行してください。
例
たとえば、データを保持する 2 つのノード（プライマリとセカンダリ）を持つ次のレプリカセットでは、アービタは、均衡を破るためにセットが奇数の投票数を集めることを許可します。
