自己管理型レプリカセットへのアービタの追加
状況によっては（プライマリとセカンダリがあるものの、コストの制約により別のセカンダリを追加できない場合など）、選挙で投票するアービタとしてレプリカセットに mongod インスタンスを追加することを選択できます。
アービターは、mongod インスタンスであり、レプリカセットの一部ですが、データを保持しません（つまり、データの冗長性を提供しません）。しかし、選挙に参加することはできます。
アービタには最小限のリソース要件があり、専用のハードウェアは必要ありません。アービターは、アプリケーション サーバーまたは監視ホストに配置できます。
重要
replica setのプライマリ メンバーまたはセカンダリ メンバーもホストするシステムでは、アービターを実行しないでください。
警告
レプリカセットに複数のアービタを配置しないでください。「複数のアービタに関する懸念事項」を参照してください。
既存のレプリカセットにアービタを追加するには、次のようにします。
通常、レプリカセットにデータを保持するノードが 2 つ以下の場合は、最初にクラスター全体の書込み保証 (write concern) をレプリカセットに設定しなければならない場合があります。
クラスター全体の書込み保証 (write concern) を設定する必要がある理由の詳細については、「クラスター全体の書込み保証 (write concern)」を参照してください。
アービタを使用して新しいレプリカセットを開始する前に、クラスター全体の書込み保証 (write concern) を変更する必要はありません。
Considerations
アービタは季刊 Rapid Releaseではサポートされません。配置にアービタが含まれている場合は、 LTSリリースのみを使用してください。
プライマリ-セカンダリ-アービタ レプリカセット
3 ノードのプライマリセカンダリアービタ（PSA）アーキテクチャを使用している場合は、次の点を考慮してください。
セカンダリが使用できなくなったり遅延が発生したりすると、 書込み保証 (write concern
"majority"によってパフォーマンスの問題が発生することがあります。 こうした問題を軽減するためのアドバイスについては、「自己管理型 PSA レプリカセットのパフォーマンスの問題の軽減 」を参照してください。グローバル デフォルト
"majority"を使用しており、書込み保証 (write concern) が過半数のサイズより小さい場合、クエリは古い（完全には複製されていない）データを返すことがあります。
アービタ
アービタはデータを保存しませんが、アービタの mongod プロセスがレプリカセットに追加されるまで、アービタは他の mongod プロセスと同様に動作し、データ ファイルのセットとフルサイズのジャーナルを使用して起動します。
IP バインディング
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
MongoDB バイナリ（mongod と mongos）は、デフォルトで localhost にバインドされます。バイナリに net.ipv6 構成ファイルや --ipv6 コマンド ライン オプションが設定されている場合、バイナリはローカルホストの IPv6 アドレスに追加でバインドされます。
デフォルトでは、localhost にバインドされているmongodとmongosは、同じコンピューター上で実行されているクライアントからの接続のみを受け入れます。 このバインディング動作には、 mongoshやレプリカセットまたはシャーディングされたクラスターのノードなどが含まれます。 リモート クライアントは、ローカルホストのみにバインドされているバイナリには接続できません。
デフォルトのバインドをオーバーライドして、他の IP アドレスにバインドするには、net.bindIp 構成ファイル設定や --bind_ip コマンド ライン オプションを使用して、ホスト名または IP アドレスのリストを指定します。
警告
MongDB5.0 以降、 スプリットホライズンDNS IP アドレスのみが設定されているノードは起動時の検証に失敗し、エラーを報告します。詳しくはdisableSplitHorizonIPCheckを参照してください。
たとえば、次の mongod インスタンスは、IP アドレス 198.51.100.1 に関連付けられているローカルホストとホスト名 My-Example-Associated-Hostname の両方にバインドします。
mongod --bind_ip localhost,My-Example-Associated-Hostname
このインスタンスに接続するには、リモート クライアントはホスト名またはそれに関連付けられた IP アドレス198.51.100.1を指定する必要があります。
mongosh --host My-Example-Associated-Hostname mongosh --host 198.51.100.1
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
アービタを追加する
警告
レプリカセットに複数のアービタを配置しないでください。「複数のアービタに関する懸念事項」を参照してください。
既存のレプリカセットにアービタを追加するには、次のようにします。
通常、レプリカセットにデータを保持するノードが 2 つ以下の場合は、最初にクラスター全体の書込み保証 (write concern) をレプリカセットに設定しなければならない場合があります。
クラスター全体の書込み保証 (write concern) を設定する必要がある理由の詳細については、「クラスター全体の書込み保証 (write concern)」を参照してください。
アービタを使用して新しいレプリカセットを開始する前に、クラスター全体の書込み保証 (write concern) を変更する必要はありません。
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
アービタに対するデータディレクトリ（例:
storage.dbPath）を作成します。mongodインスタンスは、構成データ用にディレクトリを使用します。ディレクトリにはデータセットは保存されません。たとえば、/var/lib/mongodb/arbディレクトリを作成します。mkdir /var/lib/mongodb/arb データ ディレクトリと、参加するレプリカセットの名前を指定して、アービタを起動します。以下は、
/var/lib/mongodb/arbをdbPathとして使用し、rsをレプリカセット名として使用してアービタを起動します。警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
mongod --port 27017 --dbpath /var/lib/mongodb/arb --replSet rs --bind_ip localhost,<hostname(s)|ip address(es)> プライマリに接続し、アービタをレプリカセットに追加します。次の例のように、
rs.addArb()メソッドを使用します。この例では、m1.example.netはアービタの指定された IP アドレスに関連付けられたホスト名であると想定しています。rs.addArb("m1.example.net:27017") この操作は、
m1.example.netホストのポート27017で実行されているアービタを追加します。