私のお気に入りのプロジェクト (予想を超えて成長したプロジェクト) では、なんらかの形式の負荷分散と障害に対する安全性を追加する必要があります。このプロジェクトでは、次の 3 つのレイヤーを使用します。
- フロントエンド (顧客がアクセスするもの)
- ミドルウェア (フロントエンドとバックエンド間の通信を提供)
- バックエンド（ビジネスロジック、データストレージ）
ミドルウェアは Java サーブレット、バックエンドは PostgreSQL です。顧客ごとに 1 つのデータベースがあるため、常に DB が行き来しています。新しいデータは 24 時間ごとに 1 回インポートされ、それ以外の時間は基本的に読み取り専用であるため、バックエンドは非常にシンプルです。
システム全体の回復力を高める (サーバーの障害、負荷の急増など) ために、バックエンドを他のサーバーに複製したいと考えています。その後、ミドルウェアは実行中のすべてのバックエンドにリクエストを均等に分散できます。
問題は、レプリケーションにどのようにアプローチするかです。
- ミドルウェアにすべての作業を任せます (DB ダンプを作成し、そのダンプを他のバックエンド サーバーにプッシュして復元します)。
- Postgres の組み込みメカニズム (Slony、ストリーミング リプリケーションなど) を使用します。
どちらの方法にも長所と短所があり、どちらも完全に正しいとは思えません。私の主な考えは次のとおりです。
- ミドルウェアを使用すると、制御が強化され、現在存在する顧客をより簡単に特定して、それらの DB のみをレプリケートできます。新しいバックエンド サーバーをクラスターに追加するのがより簡単になります。オンデマンドでレプリケーションを実行できます。この顧客の新しいデータがインポートされたとき。pg_dump と pg_restore を正しく処理するには、かなりの開発作業が必要です。
- 組み込みのメカニズムを使用すると、いくつかの作業が節約され、パフォーマンスと信頼性が向上する可能性があります。バックエンド サーバー (SSH、VPN) 間に何らかの通信チャネルを提供する必要があります。
それで、ここでより良いアプローチは何ですか？私はミドルウェア オプションを好む傾向がありますが、それは Postgres の経験が非常に限られているためかもしれません。
おまけの質問: Postgres レプリケーションがより良いオプションである場合、どのメカニズム (現在 Postgres 9 にはかなりの数があります) が私のシナリオに最適ですか?