本番環境でのMongoDBのデプロイは、適切なデプロイパターンが守られている場合にのみ実際に機能します。レプリカセットを単一のホストにデプロイしても、データの高可用性が保証されるわけではありません。ビッグデータを処理するには、利用可能なオプションを組み合わせるか、最も有望なメリットを備えたオプションを選択することにより、広範な調査と最適な実装が必要です。
MongoDBのデプロイパターンは次のとおりです。
- 3つのメンバーのレプリカセット
- 2つ以上のデータセンターに分散されたレプリカセット。
3つのメンバーレプリカセット
レプリケーションは、データの高可用性を強化するMongoDBのスケーリング戦略です。レプリカセットには以下が含まれます：
- プライマリノード：すべての書き込みスループット操作を担当し、そこから読み取ることもできます。
- セカンダリノード：読み取り操作にのみ使用できますが、既存のノードに障害が発生した場合にプライマリに選択できます。セットの主要メンバーによって生成されたoplogからデータの更新を取得します。
レプリカセットのメリットは、次のアーキテクチャを備えた3つのメンバーの最小数でのみ達成できます。
これは、フォールトトレランスが高く、コストなどの3番目のデータベアリングメンバーを追加する際の制限に対処するため、最も推奨されます。
この展開では、プライマリデータに加えて常に2つの完全なコピーが提供されるため、高可用性が確保されます。プライマリに障害が発生すると、レプリカセットがトリガーされて新しいプライマリが選択され、通常どおりにサービング操作が再開されます。古いプライマリが有効になると、セカンダリメンバーとして分類されます。
選挙プロセス中、メンバーはハートビートとこの間、書き込み操作は行われません
選挙プロセスの後、アーキテクチャは次のように改革されると想定します。
>
これにより、セカンダリからプライマリへの選出プロセスが容易になり、プライマリまたはセカンダリが使用できない場合でもレプリカセットが使用可能になります。アービターはデータのコピーを一切持たないため、管理に必要なリソースが少なくて済みます。
- 書き込みの可用性：投票レプリカセットメンバーの大部分は、書き込み操作を担当するプライマリを維持または選出するために必要です。
- データの冗長性：ロールバックを回避するために、複数のメンバーが書き込みを確認できます
Primary-Secondary-Arbiter構成は、セットの1つのメンバーが使用できない場合でもプライマリを維持できるように、書き込み可用性の側面のみをサポートします。
ただし、2番目の側面をサポートできないと、2番目のメンバーが使用できなくなった場合に、運用上の結果が発生します。
- 特にセカンダリが長時間オフラインの場合、アクティブなレプリケーションはありません。セカンダリが長時間オフラインになっていると、oplogから外れて、再起動中にセカンダリを再同期する必要が生じる場合があります。
- データの冗長性が妨げられ、書き込み操作が現在のプライマリによってのみ確認されるようになります。
- 大多数の懸念オプションは、接続されたアプリケーションと内部プロセスに最新のデータを提供しません。これは、構成で書き込みが過半数の確認応答を要求することを想定しているため、データを保持するメンバーの過半数が使用可能になるまでブロックされる場合です。
- レプリカセットがシャードクラスターの一部である場合、シャード間のチャンク移行も危険にさらされます。
- ロールバックが発生し、マジョリティコミットポイントを進めることができない場合のWiredTigerストレージエンジンキャッシュへの圧力。
これらの結果を回避するために、フォールトトレランスが向上するため、プライマリ-セカンダリ-セカンダリ構成を選択できます。
注：フォールトトレランスは、障害が発生した場合だけでなく、ソフトウェアのアップグレードや通常のメンテナンスなどの一部のシステム操作によって、メンバーが一時的に使用できなくなる場合があります。
2つ以上のデータセンターに分散されたレプリカセット
レプリカセットのメンバーを地理的に異なるデータセンターに分散させることで、高可用性を別のレベルに引き上げることができます。このアプローチにより、データセンターが使用できなくなった場合に備えて高いフォールトトレランスを確保するだけでなく、冗長性を高めることができます。
すべてのメンバーが単一のデータセンターに配置されている場合、レプリカセットは、ネットワークの一時的な停止や停電などのデータセンターの障害の影響を受けやすくなります。
少なくとも1人のメンバーを代替データセンターに保持することをお勧めします、奇数のデータセンターを使用し、選挙に過半数を提供するか、少なくとも失敗した場合にデータのコピーを提供するメンバーの分布を選択します。
構成では、データセンターがダウンした場合でも、残りのメンバーが選挙を行うことができるため、レプリカセットは書き込み可能なままである必要があります。
メンバーはリソースに制限されているか、ネットワークに制約があるため、フェイルオーバーの場合にプライマリになるのに適さない場合があります。これらのメンバーに優先度0を与えることで、これらのメンバーがプライマリにならないように構成できます。
データセンターのメンバーは、他のデータセンターのメンバーよりも優先順位が高く、他のデータセンターのメンバーよりも優先してプライマリを選出できるように投票の優先順位を付けることができます。
メンバーを多数のデータセンターに分散させることで、レプリケーションのメリットをより有望なステータスに引き上げることができます。これにより、データの冗長性が確保されるだけでなく、フォールトトレランスが本質的に向上します。レプリカセットのメンバーを2つ以上のデータセンターに分散すると、次のような単一のデータセンターよりもメリットがあります。
データセンターの1つがダウンした場合でも、単一のデータセンターディストリビューションとは異なり、データは引き続き読み取りに使用できます。
少数のメンバーがいるデータセンターがダウンした場合でも、書き込み操作を確認できます。
単一のデータセンターの場合とは異なり、多数決のメンバーがいるデータセンターがダウンした場合でも、読み取り操作は可能です。