レプリカセットの主な機能は、MongoDBデプロイメントにデータの冗長性と高可用性を提供することです。つまり、レプリカセットのプライマリノードが何らかの理由でダウンした場合、セカンダリはすぐに新しいプライマリとして引き継がれます（平均で約10秒以内）。 レプリケーション を参照してください このトピックの詳細については。
公式のMongoDBドライバーは、このレプリカセットの選択イベントを認識しており、新しいプライマリへの自動再接続と操作の再試行を提供します。アプリの観点からは、データベース側では何も起こりませんでした。
複数のセカンダリを持つレプリカセットを使用するもう1つの利点は、ダウンタイムのアップグレード/メンテナンスをローリング方式でゼロにできることです。これは、1つのセカンダリをオフラインにして、メンテナンスを実行し、次に他のセカンダリでメンテナンスを実行し、最後にプライマリをステップダウンしてメンテナンスを実行することで実行できます。繰り返しになりますが、公式のMongoDBドライバーはこれらのイベントを認識しているため、ライブデータベースのメンテナンスを技術的に行うことができ、影響を最小限に抑え、アプリのダウンタイムを発生させることはありません。
これは、真のビッグサーバーが1つしかないモノリシックデータベースサーバーとは異なる哲学です。モノリシックデプロイメントにはいくつかのメリットがありますが（これもまた別の議論です:)）、MongoDBはフォールトトレラントな分散データベースとして設計されました。単一サーバーの直接的な欠点の1つは、サーバーが常に100％稼働している必要があることです。そうしないと、アプリが中断されます。レプリカセットは、100％の稼働時間を必要とする個々のサーバーに圧力をかけることなく、アプリが100％の稼働時間を実現できるように設計されています。
ボーナスとして、レプリカセットは セカンダリから読み取るようにドライバを設定することにより、読み取りのスケーラビリティを提供できます（書き込みは常にプライマリに送信する必要があります）。二次読み取りを行う場合は注意深い設計が必要であることに注意してください。これは、悪用された場合に高可用性の側面を妨げる可能性があるためです。
要約すると、レプリカセットは以下を提供できます。
- 高可用性とフォールトトレランス
- ダウンタイムのメンテナンスなし
- 読み取りをスケーリングするためのデータの冗長性
ハードウェアが100％信頼できる必要はありません。これが、本番環境でレプリカセットが強く推奨される理由です。
Replica Set DeploymentArchitectures を参照してください。 レプリカセットの展開に関する詳細については、こちらをご覧ください。