地理的に冗長な自己管理型レプリカセットを配置
Overview
このチュートリアル では、 複数の場所 のメンバーを 持つ レプリカセット を配置するプロセスについて説明します。このチュートリアルでは、3 ノードのレプリカセットと 5 ノードのレプリカセットについて説明します。 レプリカセット ノードの数が 偶数 の場合は、可能であれば別のデータ保持ノードを追加して、奇数の投票ノードを配置します。 [ 1 ]
分散レプリカセットの詳細については、「 2 つ以上のデータセンターに分散されたレプリカセット 」を参照してください。 「レプリカセット配置アーキテクチャ」および「自己管理型レプリケーション リファレンス 」も参照してください。
[1] | ( 1 、 2 )状況により別のデータ保持メンバーが禁止され、投票メンバーの数が 偶数 の場合は、代わりに アービタ を追加できます。 アービタを使用する際の考慮事項については、「レプリカセット アービタ 」を参照してください。 |
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 以降、 スプリットホライズン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
接続性
セットのすべてのノードとネットワーク内のすべてのクライアント間でネットワーク トラフィックが安全に通過できることを確認します。
次の点を考慮してください。
仮想プライベートネットワークを確立します。ネットワークトポロジーが、ローカルエリアネットワークを介して単一サイト内のノード間のすべてのトラフィックをルーティングするようにしてください。
不明なクライアントからのレプリカセットへの接続を防止するためにアクセス制御を構成します。
ネットワークとファイアウォールのルールを設定して、受信パケットと送信パケットがデフォルトの 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 つのメンバー。
2 つのデータセンター: サイト A に 2 つのノード、サイト B に 1 つのノード。レプリカセットのノードの 1 つが アービタ[1]である場合は、アービタをデータを保持するノードとともにサイト A に配布します。
注意
レプリカセットのノードを 2 つのデータセンターに分散させると、1 つのデータセンターよりもメリットがあります。2つのデータセンターに分散させた場合、
データセンターの 1 つがダウンしても、1 つのデータセンターのみを利用する場合とは異なり、データは引き続き読み取り可能です。
少数のノードを含むデータセンターがダウンした場合でも、レプリカセットは読み取り操作だけでなく書込み操作も引き続き実行できます。
ただしノードの大多数を含むデータセンターがダウンすると、レプリカセットは読み取り専用になります。
可能であれば、ノードは少なくとも 3 つのデータセンターに分散させます。コンフィギュレーションサーバー レプリカセット (CSRS)の場合、ベストプラクティスはノードを 3 つ(ノード数によってはそれ以上)のセンターに分散させることです。3 つのデータセンターを利用するにはコストが高すぎる場合の選択肢の 1 つは、会社のポリシー上可能であれば、データを含むノードを 2 つのデータセンターに均等に分散し、残りのノードをクラウドに保存することです。
適切なオプションを使用してレプリカセットの各ノードを起動します。
各メンバーに対して、次の設定でmongod
インスタンスを開始します。
レプリカセット名に
replication.replSetName
オプションを設定します。アプリケーションが複数のレプリカセットに接続する場合、各セットには異なる名前を付ける必要があります。net.bindIp
オプションをホスト名/IP またはカンマ区切りのホスト名/IP リストに設定します。配置に応じて、その他の設定を行います。
このチュートリアルでは、3 つのmongod
インスタンスが次のホストに関連付けられています。
レプリカセット ノード | Hostname |
---|---|
Member 0 | mongodb0.example.net |
Member 1 | mongodb1.example.net |
Member 2 | mongodb2.example.net |
次の例では、 --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" : NumberLong(1), "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(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
に設定します。
レプリカセット構成を表示して、ノードの
members
配列位置を決定します。 配列の位置は_id
と同じではないことに注意してください。rs.conf() レプリカセット構成オブジェクトを変数(以下の例では
cfg
)にコピーします。 次に、 変数に、ノードの正しい優先順位を設定します。 次に、変数をrs.reconfig()
に渡してレプリカセットの構成を更新します。たとえば、 配列の 3 番目のメンバー(つまり、位置 2 のメンバー)の優先順位を設定するには、次の一連のコマンドを発行します。
cfg = rs.conf() cfg.members[2].priority = 0.5 rs.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 つのデータセンターのみに分散することは避けてください。
注意
レプリカセットのノードを 2 つのデータセンターに分散させると、1 つのデータセンターよりもメリットがあります。2つのデータセンターに分散させた場合、
データセンターの 1 つがダウンしても、1 つのデータセンターのみを利用する場合とは異なり、データは引き続き読み取り可能です。
少数のノードを含むデータセンターがダウンした場合でも、レプリカセットは読み取り操作だけでなく書込み操作も引き続き実行できます。
ただしノードの大多数を含むデータセンターがダウンすると、レプリカセットは読み取り専用になります。
可能であれば、ノードは少なくとも 3 つのデータセンターに分散させます。コンフィギュレーションサーバー レプリカセット (CSRS)の場合、ベストプラクティスはノードを 3 つ(ノード数によってはそれ以上)のセンターに分散させることです。3 つのデータセンターを利用するにはコストが高すぎる場合の選択肢の 1 つは、会社のポリシー上可能であれば、データを含むノードを 2 つのデータセンターに均等に分散し、残りのノードをクラウドに保存することです。
適切なオプションを使用してレプリカセットの各ノードを起動します。
各メンバーに対して、次の設定でmongod
インスタンスを開始します。
レプリカセット名に
replication.replSetName
オプションを設定し、アプリケーションが複数のレプリカセットに接続する場合、それぞれのセットには異なる名前を付ける必要があります。一部のドライバーは、レプリカセットの名前で接続をグループ化します。
ホスト名/IP アドレスまたはコンマ区切りのホスト名/IP アドレスのリストに
net.bindIp
オプションを設定し、配置に応じて、その他の設定を行います。
このチュートリアルでは、5 つのmongod
インスタンスが次のホストに関連付けられています。
レプリカセット ノード | Hostname |
---|---|
Member 0 | mongodb0.example.net |
Member 1 | mongodb1.example.net |
Member 2 | mongodb2.example.net |
Member 3 | mongodb3.example.net |
Member 4 | mongodb4.example.net |
次の例では、 --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" : NumberLong(1), "writeConcernMajorityJournalDefault" : true, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 1, "host" : "mongodb1.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 2, "host" : "mongodb2.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 3, "host" : "mongodb3.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(0), "votes" : 1 }, { "_id" : 4, "host" : "mongodb4.example.net:27017", "arbiterOnly" : false, "buildIndexes" : true, "hidden" : false, "priority" : 1, "tags" : { }, "secondaryDelaySecs" : NumberLong(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
に設定します。
レプリカセット構成を表示して、ノードの
members
配列位置を決定します。 配列の位置は_id
と同じではないことに注意してください。rs.conf() レプリカセット構成オブジェクトを変数(以下の例では
cfg
)にコピーします。 次に、 変数に、ノードの正しい優先順位を設定します。 次に、変数をrs.reconfig()
に渡してレプリカセットの構成を更新します。たとえば、 配列の 3 番目のメンバー(つまり、位置 2 のメンバー)の優先順位を設定するには、次の一連のコマンドを発行します。
cfg = rs.conf() cfg.members[2].priority = 0.5 rs.reconfig(cfg) 注意
rs.reconfig()
shell メソッドを使用すると、現在のプライマリを強制的に降格させ、選挙が行われます。 プライマリが降格すると、すべてのクライアントは切断されます。 これは意図した動作です。 新しいプライマリを選択するのにかかる時間の中央値は通常 12 秒を超えないはずですが、スケジュールされたメンテナンス期間中にレプリカ構成の変更が行われていることを常に確認してください。
これらのコマンドが返されると、地理的に冗長な 5 ノードのレプリカセットが作成されます。
レプリカセットにプライマリがあることを確認します。
レプリカセット内のプライマリを識別するには、 rs.status()
を使用します。