アプリケーションでフェイルオーバーを処理するための代替手段としてSlonyとPGPoolを検討しています。また、少なくとも2台のDBサーバーが必要になるため、負荷分散も利用できるようです。
3878 次
1 に答える
13
これは逸話ですので、一粒の塩と一緒に取ってください。
PGPoolおよびストリーミングWALレプリケーション（ホットスタンバイを使用するかどうかに関係なく）は、データベースレプリケーションが行うべき方法で機能します。アプリケーションは、レプリケーションについて、またはそれがクラスターの一部であるかどうかについて何も知る必要はありません。他のアプリケーションと同じように、データベースと通信するだけです。ストリーミングレプリケーションは堅牢であり、ストリーミングが中断した場合にWALシッピングにフェールバックする機能があります。PGPoolを使用すると、このプロセスの管理が簡単になり、適切なハートビートと監視情報が得られます。
一方、Slonyは管理上のタールピットであり、機能させるにはトリガー関数やその他の多数のオブジェクトをデータベースに追加する必要があります。さらに、Slonyは、通常の挿入/更新/削除タイプの操作（DML）を複製するのと同じように、スキーマ変更（DDL）を複製する機能を（簡単に）サポートしていません。全体として、これらの特性は、多くの場合、アプリケーションにSlonyの偏心を処理するための特別なケースが必要であることを意味します。私の意見では、それは悪いことです。アプリケーションは、実行されているデータベースレプリケーションソリューションを処理するために、認識したり変更を加えたりする必要はありません。私は1年の大部分をSlonyをハッキングして安定したレプリケーションソリューションとして機能させることに費やしましたが、最終的には、それが鈍い、判読できない方法で実装された悪いアイデア/悪いレプリケーションメカニズムであるという結論に達しました。編集： PostgreSQL 9.3以降、トリガー（Slonyが変更を検出するために使用）をDDLオブジェクトにインストールできます。これにより、Slonyはデータベースのより多くの側面を複製できる可能性があります。
とは言うものの、Slonyは、ストリーミングレプリケーション（PGPoolを介して管理されるかどうか）よりも優れた2つのことを行います。
- Slonyは、テーブルごとまたはデータベースごとのレプリケーションを可能にします。ストリーミングレプリケーションでは、Postgresインスタンス全体のレプリケーションのみが許可されます。そのような粒度が重要な場合は、Slonyが必要になる場合があります。
- Slonyは、カスケード（マスター->スレーブ->スレーブ）レプリケーションを許可します。ストリーミングレプリケーションでは、1つのレベルのみが許可されます。編集：これは、Postgresバージョン9.2以降、PostgreSQLネイティブストリーミングレプリケーションでサポートされるようになりました。
文字通り他のすべてにおいて、ストリーミングレプリケーションはより良く、より安定しています。
しかし、ストリーミングレプリケーションについて質問しているだけではありません。PGPoolはそれ以上のことを行います。これにより、読み取り専用のスレーブデータベースとマスター間の読み取りと書き込みの負荷のバランスを取り、バックアッププランを実装するだけでなく、他の多くのことを実行できます。特に、Slonyの難解なコマンド構文と恐ろしい管理スクリプトと比較すると、PGPoolはほぼすべてのインスタンスで勝ちます。
特にフェイルオーバーに関しては、PGPoolにはハートビートモニターと、クラスター内のデータベーストラフィックを自動的にルーティングする機能があります。Slonyには「今すぐスレーブにフェイルオーバー」コマンドしかなく、すべての監視とアプリ側のルーティングはあなたに任されています。
TL; DR：PGPoolは良いです。スロニー悪い。
于 2012-05-02T13:58:49.977 に答える