レプリカセット配置アーキテクチャ
レプリカセットのアーキテクチャは、セットの容量と機能に影響します。 このドキュメントでは、レプリカセットの配置戦略を示し、一般的なアーキテクチャについて説明します。
実稼働システムの標準的なレプリカセットの配置は、3 つのノードのレプリカセットです。これらのセットは冗長性とフォールト トレランスを提供します。可能な限り複雑さを避け、アプリケーションの要件に応じてアーキテクチャを決定します。
Strategies
ノード数を決定する
これらの戦略に従ってレプリカセットにノードを追加します。
投票権を有するノードの最大数
レプリカセットには最大 50 のノードを含めることができますが、投票ノードは 7 個 までです。レプリカセットにすでに 7 個の投票ノードがある場合、追加のノードは非投票ノードである必要があります。
奇数のノードを配置する
レプリカセットに奇数の投票ノードが含まれていることを確認します。レプリカセットには最大 7 個の投票ノードを含めることができます。投票ノードの数が偶数の場合は、別のデータ保持投票ノードを配置します。制約により別のデータ保持投票ノードが禁止されている場合は、アービタを配置します。
アービタはデータのコピーを保存しないため、必要なリソースが少なくなります。その結果、アプリケーション サーバーまたはその他の共有リソース上でアービタを実行できるようになります。データのコピーがない場合、レプリカセットの他のノードを配置しない環境にアービターを配置できる可能性があります。セキュリティ ポリシーをお読みください。
警告
レプリカセットに複数のアービタを配置しないでください。「複数のアービタに関する懸念事項」を参照してください。
既存のレプリカセットにアービタを追加するには、次のようにします。
通常、レプリカセットにデータを保持するノードが 2 つ以下の場合は、最初にクラスター全体の書込み保証 (write concern) をレプリカセットに設定しなければならない場合があります。
クラスター全体の書込み保証 (write concern) を設定する必要がある理由の詳細については、「クラスター全体の書込み保証 (write concern)」を参照してください。
アービタを使用して新しいレプリカセットを開始する前に、クラスター全体の書込み保証 (write concern) を変更する必要はありません。
フォールトトレランスを考慮する
レプリカセットの フォールトトレランス とは、使用できなくなっても、プライマリを選択するのに十分なノードがセット内に残っているノードの数です。言い換えれば、セット内のノードの数と、予備選挙を選出するために必要な投票ノードの majority の数との差です。プライマリがないと、レプリカセットは書込み操作を受け入れることができません。フォールトトレランスはレプリカセットのサイズに影響されますが、その関係は直接的ではありません。次の表を参照してください。
ノード数 | 新しい予備選挙を選出するには過半数が必要です | フォールトトレランス |
|---|---|---|
3 | 2 | 1 |
4 | 3 | 1 |
5 | 3 | 2 |
6 | 4 | 2 |
レプリカセットにノードを追加しても、フォールトトレランスが必ず向上するわけではありません。ただし、このような場合、追加のノードがバックアップやレポートなどの専用機能のサポートを提供できます。
rs.status()はレプリカセットのmajorityVoteCountを返します。
専用関数には隠しノードと遅延ノードを使用する
読み取り負荷の高いアプリケーション
レプリカセットは、高可用性と冗長性を実現するように設計されています。ほとんどの場合、セカンダリ ノードはプライマリ ノードと同様の負荷で動作します。セカンダリへの読み取りは行わないでください。
読み取り負荷の高いアプリケーションがある場合は、Cluster-to-Cluster Sync を使用して、読み取り用にデータを別のクラスターにレプリケートすることを検討してください。
セカンダリ読み取りモードについて詳しくは、secondary および secondaryPreferred. を参照してください。
要求される前に容量を追加する
レプリカセットの既存のノードには、新しいノードの追加をサポートするための予備容量が必要です。現在の需要によってセットの容量が飽和する前に、常に新しいノードを追加してください。
ノードを地理的に分散させる
データセンターに障害が発生した場合にデータを保護するには、少なくとも 1 つのノードを代替データセンターに保持します。可能であれば、奇数のデータセンターを使用し、データセンターが 1 つ失われた場合でも、残りのレプリカセット ノードが過半数を占めるか、少なくともデータのコピーを提供できる可能性が最大化されるノードの分散を選択します。
注意
レプリカセットのノードを 2 つのデータセンターに分散させると、1 つのデータセンターよりもメリットがあります。2つのデータセンターに分散させた場合、
データセンターの 1 つがダウンしても、1 つのデータセンターのみを利用する場合とは異なり、データは引き続き読み取り可能です。
少数のノードを含むデータセンターがダウンした場合でも、レプリカセットは読み取り操作だけでなく書込み操作も引き続き実行できます。
ただしノードの大多数を含むデータセンターがダウンすると、レプリカセットは読み取り専用になります。
可能であれば、ノードは少なくとも 3 つのデータセンターに分散させます。コンフィギュレーションサーバー レプリカセット （CSRS）の場合、ベストプラクティスはノードを 3 つ（ノード数によってはそれ以上）のセンターに分散させることです。3 つのデータセンターを利用するにはコストが高すぎる場合の選択肢の 1 つは、会社のポリシー上可能であれば、データを含むノードを 2 つのデータセンターに均等に分散し、残りのノードをクラウドに保存することです。
メインのデータセンターのノードが代替のデータセンターのノードよりも先にプライマリとして選出されるようにするには、代替のデータセンターのノードの members[n].priority をプライマリのデータセンターのノードよりも低く設定します。
詳しくは、「2 つ以上のデータセンターに分散されたレプリカセット」を参照してください。
タグセットを使用したターゲット操作
レプリカセット タグのセットを使用して、読み取り操作を特定のノードに限定したり、特定のノードに承認をリクエストするよう書き込み確認をカスタマイズしたりできます。
ジャーナリングを使用して停電から保護する
MongoDB はデフォルトで ジャーナリング を有効にします。ジャーナリングは、停電や予期しない再起動などのサービス中断が発生した場合にデータの損失を防ぎます。
ホスト名
重要
IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。
分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。
レプリカセットの名前付け
アプリケーションが複数のレプリカセットに接続する場合、それぞれのセットには異なる名前を付ける必要があります。一部のドライバーは、レプリカセットの名前で接続をグループ化します。
配置パターン
次のドキュメントでは、一般的なレプリカセットの配置パターンについて説明します。アプリケーションの要件に応じて、他のパターンも可能であり、効果的です。必要に応じて、各アーキテクチャの機能を独自の配置で組み合わせます。
- 3 つのノードのレプリカセット
- 3 ノードのレプリカセットは、レプリカセットに推奨される最小限のアーキテクチャを提供します。
- 2 つ以上のデータセンターに分散されたレプリカセット
- 地理的に分散されたセットには、停電などの施設固有の障害から保護するために、複数の場所のノードが含まれます。