Overview
This tutorial outlines the process for deploying a replica set with members in multiple locations. The tutorial addresses three-member replica sets and five-member replica sets. If you have an even number of replica set members, add another data bearing member, if possible, to deploy an odd number of voting members. [1]
分散レプリカセットの詳細については、「 2 つ以上のデータセンターに分散されたレプリカセット 」を参照してください。 「レプリカセット配置アーキテクチャ」および「自己管理型レプリケーション リファレンス 」も参照してください。
| [1] | 状況により別のデータを保持するノードを追加できない場合で、かつ投票ノードの数が偶数である場合は、代わりにアービタを追加できます。アービタを使用する際の注意事項については、「レプリカセット アービタ」を参照してください。 |
Considerations
アーキテクチャ
本番環境では、レプリカセットの各ノードを別個のマシンにデプロイします。可能であれば、MongoDB がデフォルトのポート27017でリッスンするようにしてください。
詳細については、「レプリカセットの配置アーキテクチャ」を参照してください。
ホスト名
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
IP バインディング
--bind_ipオプションを使用して、MongoDB が設定されたアドレス上のアプリケーションからの接続をリッスンするようにします。
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
MongoDB バイナリ（mongod と mongos）は、デフォルトで localhost にバインドされます。バイナリに net.ipv6 構成ファイルや --ipv6 コマンド ライン オプションが設定されている場合、バイナリはローカルホストの IPv6 アドレスに追加でバインドされます。
デフォルトでは、localhost にバインドされている mongod と mongos は、同じコンピューター上で実行中のクライアントによる接続のみを受け入れます。このバインディング動作には、mongosh や、レプリカセットやシャーディングされたクラスターのノードなどが含まれます。リモート クライアントは、ローカルホストのみにバインドされているバイナリには接続できません。
デフォルトのバインドをオーバーライドして、他の IP アドレスにバインドするには、net.bindIp 構成ファイル設定や --bind_ip コマンド ライン オプションを使用して、ホスト名または IP アドレスのリストを指定します。
警告
MongDB5.0 以降、 IPアドレスのみが設定されている分裂ホライゾン DNS ノードはスタートアップの検証に失敗し、エラーを報告します。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接続性
セットのすべてのノードとネットワーク内のすべてのクライアント間でネットワーク トラフィックが安全に通過できることを確認します。
次の点を考慮してください。
仮想プライベートネットワークを確立します。ネットワークトポロジーが、ローカルエリアネットワークを介して単一サイト内のノード間のすべてのトラフィックをルーティングするようにしてください。
不明なクライアントからのレプリカセットへの接続を防止するためにアクセス制御を構成します。
ネットワークとファイアウォールのルールを設定して、受信パケットと送信パケットがデフォルトの MongoDB ポートでのみ、デプロイ内からのみ許可されるようにします。IP バインディングに関する考慮事項を参照してください。
レプリカセットの各メンバーに、解決可能な DNS またはホスト名を使用してアクセスできることを確認します。DNS 名を適切に構成するか、この構成を反映するようにシステムの/etc/hostsファイルを設定する必要があります。
各ノードは他のすべてのノードに接続できる必要があります。接続を確認する方法については、「すべてのノード間の接続をテストする」を参照してください。
構成
MongoDB の配置前に、MongoDB がデータ ファイルを保存するディレクトリを作成します。
/etc/mongod.confまたは関係するロケーションに保存された構成ファイルでmongodを指定します。
構成オプションの詳細については、「自己管理型構成ファイル オプション 」を参照してください。
ノードの分布
可能であれば、奇数のデータセンターを使用し、データセンターが 1 つ失われた場合でも、残りのレプリカセット ノードが過半数を占めるか、少なくともデータのコピーを提供できる可能性が最大化されるノードの分散を選択します。
投票ノード
7 つを超える投票ノードを配置しないでください。
前提条件
このチュートリアルのすべての構成では、各レプリカセット ノードを個別のシステムに配置します。 1 つのシステムに複数のレプリカセット メンバーを配置できますが、レプリカセットの冗長性と容量が低下します。 このような配置は通常、テスト目的で行われます。
このチュートリアルでは、レプリカセットの一部となる各システムに MongoDB がインストールされていることを前提としています。 MongoDB をまだインストールしていない場合は、インストール チュートリアルを参照してください。
手順
地理的に冗長な 3 ノードのレプリカセットを配置する
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
地理的に冗長なレプリカセットを配置する場合は、システムの分散方法を決定する必要があります。 3 つのノードに対して可能なディストリビューションの一部は次のとおりです。
3 つのデータセンター: 各サイトに 1 つのメンバー。
Across Two Data Centers: Two members to Site A and one member to Site B. If one of the members of the replica set is an arbiter [1], distribute the arbiter to Site A with a data-bearing member.
注意
本番環境には、少なくとも 3 つのデータセンターにコンフィギュレーションサーバーとシャードレプリカセットをデプロイすることをお勧めします。この構成により、1 つのデータセンターがダウンした場合でも、高可用性が得られます。
適切なオプションを使用してレプリカセットの各ノードを起動します。
各メンバーに対して、次の設定でmongodインスタンスを開始します。
レプリカセット名に
replication.replSetNameオプションを設定します。アプリケーションが複数のレプリカセットに接続する場合、各セットには異なる名前を付ける必要があります。net.bindIpオプションをホスト名/IP またはカンマ区切りのホスト名/IP リストに設定します。配置に応じて、その他の設定を行います。
このチュートリアルでは、3 つのmongodインスタンスが次のホストに関連付けられています。
レプリカセット ノード | Hostname |
|---|---|
Member 0 |
|
Member 1 |
|
Member 2 |
|
次の例では、 --replSetおよび--bind_ipコマンドライン オプションを使用してレプリカセット名と IP バインディングを指定します。
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)><hostname(s)|ip address(es)>には、リモート クライアント（レプリカセットの他のノードを含む）がインスタンスに接続するために使用できるmongodインスタンスのホスト名や IP アドレスを指定します。
あるいは、構成ファイルでreplica set nameとip addressesを指定することもできます。
replication: replSetName: "rs0"net: bindIp: localhost,<hostname(s)|ip address(es)>構成ファイルを使用してmongodを起動するには、 --configオプションを使用して構成ファイルのパスを指定します。
mongod --config <path-to-config>本番環境では、このプロセスを管理する init スクリプトを設定できます。init スクリプトは、このドキュメントの範囲外です。
レプリカセットを開始します。
mongoshから、レプリカセット ノード0でrs.initiate()を実行します。
重要
レプリカセットに対して 1 つの mongod インスタンスでのみ rs.initiate() を実行します。
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
rs.initiate( { _id : "rs0", members: [ { _id: 0, host: "mongodb0.example.net:27017" }, { _id: 1, host: "mongodb1.example.net:27017" }, { _id: 2, host: "mongodb2.example.net:27017" } ]})MongoDB は、デフォルトのレプリカセット構成を使用してレプリカセットを開始します。
レプリカセットの構成を表示します。
レプリカセットの構成オブジェクトを表示するには、rs.conf()を使用します。
rs.conf()レプリカセットの構成オブジェクトは次のようになります。
{ "_id" : "rs0", "version" : 1, "protocolVersion" : Long(1), "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {
}, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {
}, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {
}, "secondaryDelaySecs" : Long(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "getLastErrorModes" : {
}, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("585ab9df685f726db2c6a840") }}任意。 プライマリになるためのノードの資格を設定します。
場合によっては、あるデータセンターのノードを他のデータセンターのノードよりも先にプライマリに選出したい場合があるかもしれません。 ノードのpriorityを変更して、1 つのデータセンターのノードのpriorityが他のデータセンターのノードよりも高くなるようにすることができます。
ネットワークに制約があるノードやリソースが限られているノードなど、レプリカセットの一部のノードは、フェイルオーバーでプライマリにならないようにする必要があります。プライマリになるべきではないノードの優先順位を 0 に設定します。
たとえば、いずれかのサイトにあるノードの相対的な適格性を下げるには（この例ではmongodb2.example.net ）、ノードの優先順位を0.5に設定します。
レプリカセット構成オブジェクトを変数（以下の例では
cfg）にコピーします。次に、 変数に、ノードの正しい優先順位を設定します。レプリカセットの構成を更新するには、変数をrs.reconfig()に渡します。たとえば、 配列の 3 番目のメンバー（つまり、位置 2 のメンバー）の優先順位を設定するには、次の一連のコマンドを発行します。
cfg = rs.conf()cfg.members[2].priority = 0.5rs.reconfig(cfg)注意
rs.reconfig()shell メソッドを使用すると、現在のプライマリを強制的に降格させることができ、選挙が行われます。プライマリが降格すると、すべてのクライアントが切断されます。これは意図した動作です。新しいプライマリを選出するまでの中央値は通常 12 秒を超えてはなりません。レプリカの構成変更は、必ず予定されたメンテナンス期間中に行ってください。
これらのコマンドが返されると、地理的に冗長な 3 ノードのレプリカセットが作成されます。
レプリカセットにプライマリがあることを確認します。
レプリカセット内のプライマリを識別するには、 rs.status()を使用します。
地理的に冗長な 5 ノードのレプリカセットを配置する
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
地理的に冗長な 5 メンバーのレプリカセット配置の場合、システムの分散方法を決定する必要があります。 5 つのノードに対して可能性のある分布は次のとおりです。
3 つのデータセンターにわたる場合: サイト A に 2 つのノード、サイト B に 2 つのノード、サイト C に 1 つのノード。
4 つのデータセンター: 1 つのサイトに 2 つのノード、他の 3 つのサイトに 1 つのノード。
5 つのデータセンター: 各サイトに 1 つのメンバー。
2 つのデータセンターにまたがる: サイト A の 3 つのノードとサイト B の 2 つのノード。可能であれば、コンフィギュレーションサーバーのレプリカセットを 2 つのデータセンターのみに分散することは避けてください。
注意
本番環境には、少なくとも 3 つのデータセンターにコンフィギュレーションサーバーとシャードレプリカセットをデプロイすることをお勧めします。この構成により、1 つのデータセンターがダウンした場合でも、高可用性が得られます。
適切なオプションを使用してレプリカセットの各ノードを起動します。
各メンバーに対して、次の設定でmongodインスタンスを開始します。
レプリカセット名に
replication.replSetNameオプションを設定し、アプリケーションが複数のレプリカセットに接続する場合、それぞれのセットには異なる名前を付ける必要があります。一部のドライバーは、レプリカセットの名前で接続をグループ化します。
ホスト名/IP アドレスまたはコンマ区切りのホスト名/IP アドレスのリストに
net.bindIpオプションを設定し、配置に応じて、その他の設定を行います。
このチュートリアルでは、5 つのmongodインスタンスが次のホストに関連付けられています。
レプリカセット ノード | Hostname |
|---|---|
Member 0 |
|
Member 1 |
|
Member 2 |
|
Member 3 |
|
Member 4 |
|
次の例では、 --replSetおよび--bind_ipコマンドライン オプションを使用してレプリカセット名と IP バインディングを指定します。
警告
インスタンスをパブリックにアクセス可能な IP アドレスにバインドする前に、クラスターを不正アクセスから保護する必要があります。 セキュリティ推奨事項の完全なリストについては、「自己管理型配置のセキュリティ チェックリスト」を参照してください。 最低限、認証を有効化し、ネットワーク インフラストラクチャの強化 を検討してください。
mongod --replSet "rs0" --bind_ip localhost,<hostname(s)|ip address(es)><hostname(s)|ip address(es)>には、リモート クライアント（レプリカセットの他のノードを含む）がインスタンスに接続するために使用できるmongodインスタンスのホスト名や IP アドレスを指定します。
あるいは、構成ファイルでreplica set nameとhostnames/ip addressesを指定することもできます。
replication: replSetName: "rs0"net: bindIp: localhost,<hostname(s)|ip address(es)>構成ファイルを使用してmongodを起動するには、 --configオプションを使用して構成ファイルのパスを指定します。
mongod --config <path-to-config>本番環境では、このプロセスを管理する init スクリプトを設定できます。init スクリプトは、このドキュメントの範囲外です。
レプリカセットを開始します。
mongoshから、レプリカセット ノード0でrs.initiate()を実行します。
重要
レプリカセットに対して 1 つの mongod インスタンスでのみ rs.initiate() を実行します。
rs.initiate( { _id : "rs0", members: [ { _id: 0, host: "mongodb0.example.net:27017" }, { _id: 1, host: "mongodb1.example.net:27017" }, { _id: 2, host: "mongodb2.example.net:27017" }, { _id: 3, host: "mongodb3.example.net:27017" }, { _id: 4, host: "mongodb4.example.net:27017" } ]})レプリカセットの構成を表示します。
レプリカセットの構成オブジェクトを表示するには、rs.conf()を使用します。
rs.conf()レプリカセットの構成オブジェクトは次のようになります。
{ "_id" : "rs0", "version" : 1, "protocolVersion" : Long(1), "writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {
}, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {
}, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {
}, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 3, "host" : "mongodb3.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {
}, "secondaryDelaySecs" : Long(0), "votes" : 1 }, { "_id" : 4, "host" : "mongodb4.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : {
}, "secondaryDelaySecs" : Long(0), "votes" : 1 } ], "settings" : { "chainingAllowed" : true, "heartbeatIntervalMillis" : 2000, "heartbeatTimeoutSecs" : 10, "electionTimeoutMillis" : 10000, "catchUpTimeoutMillis" : -1, "catchUpTakeoverDelayMillis" : 30000, "getLastErrorModes" : {
}, "getLastErrorDefaults" : { "w" : 1, "wtimeout" : 0 }, "replicaSetId" : ObjectId("5df2c9ccc21c478b838b98d6") }}任意。 プライマリになるためのノードの資格を設定します。
場合によっては、あるデータセンターのノードを他のデータセンターのノードよりも先にプライマリに選出したい場合があるかもしれません。 ノードのpriorityを変更して、1 つのデータセンターのノードのpriorityが他のデータセンターのノードよりも高くなるようにすることができます。
ネットワークに制約があるノードやリソースが限られているノードなど、レプリカセットの一部のノードは、フェイルオーバーでプライマリにならないようにする必要があります。プライマリになるべきではないノードの優先順位を 0 に設定します。
たとえば、いずれかのサイトにあるノードの相対的な適格性を下げるには（この例ではmongodb2.example.net ）、ノードの優先順位を0.5に設定します。
レプリカセット構成オブジェクトを変数（以下の例では
cfg）にコピーします。次に、 変数に、ノードの正しい優先順位を設定します。レプリカセットの構成を更新するには、変数をrs.reconfig()に渡します。たとえば、 配列の 3 番目のメンバー（つまり、位置 2 のメンバー）の優先順位を設定するには、次の一連のコマンドを発行します。
cfg = rs.conf()cfg.members[2].priority = 0.5rs.reconfig(cfg)注意
rs.reconfig()shell メソッドを使用すると、現在のプライマリを強制的に降格させることができ、選挙が行われます。プライマリが降格すると、すべてのクライアントが切断されます。これは意図した動作です。新しいプライマリを選出するまでの中央値は通常 12 秒を超えてはなりません。レプリカの構成変更は、必ず予定されたメンテナンス期間中に行ってください。
これらのコマンドが返されると、地理的に冗長な 5 ノードのレプリカセットが作成されます。
レプリカセットにプライマリがあることを確認します。
レプリカセット内のプライマリを識別するには、 rs.status()を使用します。