クラスタリングでPostgreSQLの可用性と信頼性を高める
PostgreSQL用のレプリケーション・ソフト（1）pgpool-II
このページでは、PostgreSQL用のレプリケーション・ソフトとして、（1）pgpool-IIと（2）Slony-Iの2つを紹介します。
（1）pgpool-II（http://pgpool.projects.postgresql.org/pgpool-II/doc/pgpool-ja.html）は、PostgreSQLのレプリケーションとフェイル・オーバーを実現するソフトです。さらに、データベースとの接続を維持するコネクション・プーリングや、負荷分散といった機能も含んでいます。従来はpgpoolという名前で知られていたソフトの後継ソフトに相当します。
pgpool-IIは、PostgreSQLのプロキシ（代理）・サーバーとして動作します。クライアントからのSQL要求を引き受け、後ろに控える複数台のPostgreSQLサーバー（バックエンド・サーバー）に代理アクセスします。これにより、データのレプリケーションが可能になります。すべてのバックエンドサーバーから処理が返ってきてからクライアントに返答を返す同期レプリケーションの仕組みを採用しているため、pgpool-II経由でコミットした処理は、確実にバックエンド・サーバーにも反映されます。
バックエンド・サーバーのいずれかが障害を起こした場合、ほかのバックエンド・サーバーでフェイル・オーバーします。フェイル・オーバー後は、pgpool-IIによるシステム全体を稼働させたまま、障害を起こしたバックエンド・サーバーの撤去や、新たなバックエンド・サーバーの追加が可能です。
pgpool-IIの弱点は、プロキシ・サーバーであるpgpool-II本体を配置するサーバー部分です。この部分が障害を起こすと、システム全体が止まってしまいます。そこで、pgpool-II本体をHAクラスタ・ソフトで保護するというアプローチが有効です。オープンソースのクラスタ・ソフトであるHeartbeat向けの監視起動スクリプトが、pgpool-HA（http://pgfoundry.org/projects/pgpool/）として配布されています。
pgpool-IIは、SQL文（SQLトランザクション）レベルでのレプリケーションとなるため、同じSQL文でも結果が都度異なるようなケースだと、バックエンド・サーバー間でデータが一致しなくなります。典型的な例は、乱数を生成して格納したり、現在時間を問い合わせて格納するといったものです。また、連番を生成する場合も、テーブルをロックする処理が必要になります。既存システムでpgpool-IIのレプリケーション機能を使う場合は、問題となる個所がないか事前にチェックして、修正する必要があります。
PostgreSQL用のレプリケーション・ソフト（2）Slony-I
（2）Slony-I（http://www.slony.info/）は、PostgreSQLデータベースを行レベルで非同期にレプリケーションするソフトです。テーブルを更新すると、その内容を少し遅れてスレーブ・サーバーに適用します。1台のマスター・サーバーに対して、スレーブ・サーバーは何台でも、また何段にでも設置できます。スレーブ・サーバーのPostgreSQLは、クライアントからは参照専用となります。
Slony-Iは、テーブル単位でレプリケーションの対象を設定できます。このため、複雑なことができる一方で、設定はやや煩雑です。また、Slony-Iは、レプリケーション（データ・コピー）機能しか提供しませんので、障害を監視して、障害時に処理を切り替える仕組みが別途必要です。可用性の要求レベルによっては、管理者が手動で実施してもよいでしょう。
上述したpgpool-IIとSlony-Iを組み合わせてpgpool-IIにフェイル・オーバーさせる構成も可能です。Slony-Iは、ラージ・オブジェクトが使えないほかにはSQLに制約がないため、レプリケーションにpgpool-IIの機能を使ったことで発生しうるデータの不一致を避けたい場合に、この組み合わせが好まれます。
