PostgreSQLでのストリーミングレプリケーションとフェイルオーバー
私はPostgreSQLレプリケーションの概念実証を行っています。フォーラムでの議論の後、他のソリューションと比較してパフォーマンスが良いため、ストリーミングレプリケーションを採用することにしました。 PostgreSQLはストリーミングレプリケーションの自動フェイルオーバーを提供していません。トリガーファイルを使用してスレーブをマスターに切り替えることができますが、管理できません。したがって、自動フェイルオーバーと高可用性を備えたソリューションが欲しいのです。
さまざまなソリューションが利用可能です：
- Repmgr
- Linuxハートビート
- Pgpool-II（自動フェイルオーバーのみ）
- 使用した場合のその他のツール。
私の質問は、どのソリューションを使用する必要があるかです。
当店ではpgpoolの代わりにrepmgrとpgbouncerを選択しました。 repmgrには、レプリケートされたデータベースサーバーのクラスターをセットアップおよび維持するためのいくつかの素晴らしいツールがあります。この例では、1つのマスターと2つのスレーブ（1つのフェイルオーバーと、新しいマスターのフェイルオーバーになる可能性がある1つのライブ読み取りパフォーマンステスト）。 pgpoolには設定の変更に関する問題があります。ほとんどの場合、サービスを再起動する必要があるため、ダウンタイムが生じます。 24時間365日の可用性が必要な場合、これは問題です。
repmgrd（デーモン）は、フェイルオーバー後に新しいマスターを選択するのに役立ちます。スプリットブレインの状況は必要ありません。マスターデータベースの仮想IPアドレスが1つあります。このデータベースは、その時点でマスターです。別のサーバーがマスターになると、これがこのアドレスを使用する唯一のサーバーになります。すべてのデータベースサーバーには、読み取り専用クエリ用の独自のIPアドレスもあります。
repmgrは、そもそもストリーミングレプリケーションを作成したのと同じ人たちによって管理されているため、彼らは自分たちの話を知っています。バージョン2.0がまもなくリリースされます。
最悪の状況に備えて、電源プラグとネットワークプラグを抜いて真面目なテストをしてください！何かがうまくいかないとき、他の多くのことがすでにうまくいかず、あなたがそれを買う余裕がないとき、あなたを後ろから噛みます。
レプリケーションは1つのことであり、いくつかの深刻な問題が発生した後にフェイルオーバーが機能することは、別のことです。
2つの異なるソリューションを同時に使用しています...
同期レプリケーションの場合はPgpool-II、非同期（トリガー）レプリケーションの場合はSlony2。
性能は素晴らしい