Docs Menu
Docs Home
/
MongoDBマニュアル
/

レプリカセット配置アーキテクチャ

項目一覧

  • Strategies
  • レプリカセットの名前付け
  • 配置パターン

レプリカセットのアーキテクチャは、セットの容量と機能に影響します。 このドキュメントでは、レプリカセットの配置戦略を示し、一般的なアーキテクチャについて説明します。

実稼働システムの標準的なレプリカセットの配置は、3 つのノードのレプリカセットです。これらのセットは冗長性とフォールト トレランスを提供します。可能な限り複雑さを避け、アプリケーションの要件に応じてアーキテクチャを決定します。

注意

これらの戦略に従ってレプリカセットにノードを追加します。

レプリカセットには最大 50 のノードを含めることができますが、投票ノードは 7 個 までです。レプリカセットにすでに 7 個の投票ノードがある場合、追加のノードは非投票ノードである必要があります。

レプリカセットに奇数の投票ノードが含まれていることを確認します。レプリカセットには最大 7 個の投票ノードを含めることができます。投票ノードの数が偶数の場合は、別のデータ保持投票ノードを配置します。制約により別のデータ保持投票ノードが禁止されている場合は、アービタを配置します。

アービタはデータのコピーを保存しないため、必要なリソースが少なくなります。その結果、アプリケーション サーバーまたはその他の共有リソース上でアービタを実行できるようになります。データのコピーがない場合、レプリカセットの他のノードを配置しない環境にアービターを配置できる可能性があります。セキュリティ ポリシーをお読みください。

警告

レプリカセットごとに複数のアービタを配置しないでください。

複数のアービタに関する懸念」も参照してください

レプリカセットの フォールトトレランス とは、使用できなくなっても、プライマリを選択するのに十分なノードがセット内に残っているノードの数です。言い換えれば、セット内のノードの数と、予備選挙を選出するために必要な投票ノードの majority の数との差です。プライマリがないと、レプリカセットは書込み操作を受け入れることができません。フォールトトレランスはレプリカセットのサイズに影響されますが、その関係は直接的ではありません。次の表を参照してください。

ノード数
新しい予備選挙を選出するには過半数が必要です
フォールトトレランス
3
2
1
4
3
1
5
3
2
6
4
2

レプリカセットにノードを追加しても、フォールトトレランスが必ず向上するわけではありません。ただし、このような場合、追加のノードがバックアップやレポートなどの専用機能のサポートを提供できます。

rs.status()はレプリカセットのmajorityVoteCountを返します。

バックアップやレポートなどの専用機能をサポートするには、隠しノードまたは 遅延 ノードを追加します。

レプリカセットは、高可用性と冗長性を実現するように設計されています。ほとんどの場合、セカンダリ ノードはプライマリ ノードと同様の負荷で動作します。セカンダリへの読み取りは行わないでください。

セカンダリ読み取りモードについて詳しくは、secondary および secondaryPreferred. を参照してください。

レプリカセットの既存のノードには、新しいノードの追加をサポートするための予備容量が必要です。現在の需要によってセットの容量が飽和する前に、常に新しいノードを追加してください。

データセンターに障害が発生した場合にデータを保護するには、少なくとも 1 つのノードを代替データセンターに保持します。可能であれば、奇数のデータセンターを使用し、データセンターが 1 つ失われた場合でも、残りのレプリカセット ノードが過半数を占めるか、少なくともデータのコピーを提供できる可能性が最大化されるノードの分散を選択します。

注意

レプリカセットのノードを 2 つのデータセンターに分散させると、1 つのデータセンターよりもメリットがあります。2つのデータセンターに分散させた場合、

  • データセンターの 1 つがダウンしても、1 つのデータセンターのみを利用する場合とは異なり、データは引き続き読み取り可能です。

  • 少数のノードを含むデータセンターがダウンした場合でも、レプリカセットは読み取り操作だけでなく書込み操作も引き続き実行できます。

  • ただしノードの大多数を含むデータセンターがダウンすると、レプリカセットは読み取り専用になります。

可能であれば、ノードは少なくとも 3 つのデータセンターに分散させます。コンフィギュレーションサーバー レプリカセット (CSRS)の場合、ベストプラクティスはノードを 3 つ(ノード数によってはそれ以上)のセンターに分散させることです。3 つのデータセンターを利用するにはコストが高すぎる場合の選択肢の 1 つは、会社のポリシー上可能であれば、データを含むノードを 2 つのデータセンターに均等に分散し、残りのノードをクラウドに保存することです。

メインのデータセンターのノードが代替のデータセンターのノードよりも先にプライマリとして選出されるようにするには、代替のデータセンターのノードの members[n].priority をプライマリのデータセンターのノードよりも低く設定します。

詳しくは、「2 つ以上のデータセンターに分散されたレプリカセット」を参照してください。

レプリカセット タグのセットを使用して、読み取り操作を特定のノードに限定したり、特定のノードに承認をリクエストするよう書き込み確認をカスタマイズしたりできます。

Tip

以下も参照してください。

MongoDB はデフォルトで ジャーナリング を有効にします。ジャーナリングは、停電や予期しない再起動などのサービス中断が発生した場合にデータの損失を防ぎます。

重要

IP アドレスの変更による構成の更新を防ぐには、IP アドレスの代わりに DNS ホスト名を使用します。レプリカセット ノードまたはシャーディングされたクラスター ノードを設定するときは、IP アドレスではなく DNS ホスト名を使用することが特に重要です。

分裂されたネットワーク ホライズン全体でクラスターを構成するには、IP アドレスの代わりにホスト名を使用します。 MongoDB 5.0以降、IP アドレスのみが設定されているノードは起動時の検証に失敗し、起動しません。

アプリケーションが複数のレプリカセットに接続する場合、それぞれのセットには異なる名前を付ける必要があります。一部のドライバーは、レプリカセットの名前で接続をグループ化します。

次のドキュメントでは、一般的なレプリカセットの配置パターンについて説明します。アプリケーションの要件に応じて、他のパターンも可能であり、効果的です。必要に応じて、各アーキテクチャの機能を独自の配置で組み合わせます。

3 つのノードのレプリカセット
3 ノードのレプリカセットは、レプリカセットに推奨される最小限のアーキテクチャを提供します。
2 つ以上のデータセンターに分散されたレプリカセット
地理的に分散されたセットには、停電などの施設固有の障害から保護するために、複数の場所のノードが含まれます。

戻る

アービタ