ネットワークコストを最小限に抑える最高のPostgreSQLレプリケーションソリューション
PostgreSQLレプリケーションソリューションを調べています。私はこれらのソリューションの2つの種類を知っています
- 低レベル-PostgreSQL9.xで利用可能なストリーミングログ配布、ホットスタンバイ機能が含まれます
- 高レベル-SQLクエリレベルで機能するSlony、Londiste
私のデータベースはそれほど忙しくなく、巨大ではありません（少なくとも今は）。ただし、Amazon EC2の障害（最近発生した障害など）によるダウンタイムは避けたいと思います。私の解決策は、マスターデータベースインスタンスとの同期を維持する別のアベイラビリティーゾーンにスレーブを維持することです。そうすれば、マスターがダウンしたときにフェイルオーバーできます。考慮すべき点の1つは、マスターからスレーブへのデータの継続的なレプリケーションが必要になることです。これは、EC2アベイラビリティーゾーン全体のネットワークトラフィックになります。それは無料ではありません。現在、GBあたり1セントの費用がかかりますが、PostgreSQLクックブックの計算を読んだ後、DBトラフィックが少なくてもコストが非常に高くなる可能性があることを学びました。たとえば、 "PostgreSQL 9 Administration Cookbook" の「ホットフィジカルバックアップと継続的なアーカイブ」の章で、私はこれを読みました：
Archive_timeoutが30秒に設定されている場合、1日あたり最小2 * 60 * 24 = 2880ファイルが生成され、各ファイルのサイズは16 MBであるため、1日あたりの合計ボリュームは46 GB（最小）になります。
[そして、DBのトラフィックが最小限であると仮定します]
私の唯一の要件は、マスターサーバーで実行される各書き込みSQLクエリを、スレーブサーバーで再生する必要があることです。これがイベントコールバックで行われる場合、DBに変更が加えられていなくても、DBが変更されているときのみ、30秒ごとではなく、マスターとスレーブ間でデータ転送が行われるため、これは完璧です。
したがって、Londisteが私にとっての解決策かもしれないと思いましたが、それがそのように機能するかどうかは100％確信していません。
何を指示してるんですか？
1週間の調査の後、私はStreaming Log ShippingおよびHot Standby PostgreSQLインスタンスの構成は、インスタントレプリケーション（データ損失の最小ウィンドウ）のニーズに対応しますが、ネットワークトラフィックは少なくなります。私はそれをどのように設定したかについて詳細な ブログ投稿 を書きました。
Pgpoolのようなサードパーティのツールを使用する他の解決策もあるかもしれませんが、私はそれらであまり成功しませんでした。
pgpool をご覧ください。私たちは仕事で本番環境で使用しており、これまでのところ非常に満足しています。 SQLクエリの混乱から保護されないため、バックアップを作成する必要があることは明らかですが、同期/レプリケーションは美しく行われます。