PostgreSQLでのストリーミングレプリケーションとフェールオーバー

PostgreSQLレプリケーションの概念実証を行っています。フォーラムでの議論の後、パフォーマンスが他のソリューションと比較して優れているため、ストリーミングレプリケーションを使用することにしました。PostgreSQLは、ストリーミングレプリケーションの自動フェールオーバーを提供していません。トリガーファイルを使用してスレーブをマスターに切り替えることはできますが、管理はできません。そこで、自動フェイルオーバーと高可用性を備えたソリューションが欲しいのです。

さまざまなソリューションが利用可能です。

1. Repmgr
2. Linuxハートビート
3. Pgpool-II（自動フェイルオーバーのみ）
4. 使用した場合のその他のツール。

私の質問は、どのソリューションを使用する必要があるのですか？

当店では、pgpoolではなくrepmgrとpgbouncerを選択しました。repmgrには、複製されたデータベースサーバーのクラスターをセットアップおよび維持するための優れたツールがあります。この場合、1つのマスターと2つのスレーブ（1つのフェールオーバーと、新しいマスターのフェールオーバーになる可能性のあるライブ読み取りパフォーマンステスト）。pgpoolには設定の変更に関する問題があります。ほとんどの場合、サービスを再起動する必要があるため、ダウンタイムが発生します。これは、24時間365日の可用性が必要な場合の問題です。

repmgrd（デーモン）は、フェールオーバー後に新しいマスターを選択するのに役立ちます。スプリットブレインの状況は本当に望ましくありません。masterデータベース用の仮想IPアドレスが1つあります。その時点でマスターであるデータベースです。別のサーバーがマスターになると、これがこのアドレスを使用する唯一のサーバーになります。また、すべてのデータベースサーバーには、読み取り専用クエリ用の独自のIPアドレスがあります。

repmgrは、最初にストリーミングレプリケーションを作成したのと同じ人によって管理されているため、彼らは何について話しているかを知っています。バージョン2.0がリリースされようとしています。

最悪の状況に備えて、電源プラグとネットワークプラグを抜いて、いくつかの深刻なテストを行ってください！何かがうまくいかないとき、他の多くのものはすでにうまくいかず、あなたがそれを買う余裕がないとき、後ろにあなたを噛みます。

レプリケーションは1つのことであり、いくつかの重大な問題が発生した後に機能するフェイルオーバーは別のことです。

2つの異なるソリューションを同時に組み合わせて使用​​しています...

同期レプリケーションの場合はPgpool-II、非同期（トリガー）レプリケーションの場合はSlony2。

優れた性能