本記事は 、Pgpool-II 4.1の新機能、2拠点に分かれたレプリケーション構成への対応を可能にする新しい設定パラメータrelcache_query_target についてご紹介します。
Pgpool-II 4.1 の概要ついては、Pgpool-II 4.1 の紹介【第 1 回】を参照ください。
本店・支店が遠隔地にある場合のレプリケーション
ある程度の規模の企業では、本店が東京、支店が大阪といったように、拠点が複数あり、しかもそれぞれが離れていることがよくあります。
ときには本店が東京、支店がニューヨークというように、国をまたいで拠点が存在することも珍しくありません。
今、ある企業で本店にPostgreSQLのストリーミングレプリケーションのプライマリサーバを置き、データベースの更新と本店社員の情報検索をそこで行い、一方支店の方にはスタンバイサーバを置いて、主に支店の社員が情報検索を行うものとします。たまにデータベースの更新を行うこともありますが、頻度は高くなく、その場合は本店のプライマリサーバに更新をかけるとします。
このような構成を取ることにより、それぞれの拠点の情報検索業務はネットワーク的に近いサーバを利用できるため、レスポンスが高速になりますし、万が一本店のサーバがダウンしても支店のサーバを昇格させることによって業務が継続できます。
Pgpool-IIによるサーバ問い合わせ自動振り分け
こうした構成では社員はそれぞれ本店のサーバにアクセスするのか支店のサーバにアクセスするのかを意識する必要があります。更にデータベースへのアクセスは通常アプリケーションを通じて行いますので、そのアプリケーションを変更しない限り、データベースのアクセス先を適切に設定することができません。しかしPgpool-IIを使えば設定によってPgpool-IIが自動的に振り分けをしてくれるので、社員はアクセス先のデータベースを意識する必要がなくなります。以下の構成では、本店、支店の社員はそれぞれ本店、支店に設置されたPgpool-IIに常にアクセスします。支店において更新クエリを本店のプライマリサーバに送出するのはPgpool-IIが行います。
リレーションキャッシュ問題
しかし従来のPgpool-IIでは、この構成はうまく動きません。なぜなら、Pgpool-IIはクエリを解析する際にクエリに含まれるテーブルなどに関する情報をプライマリサーバから取得するからです。これをリレーションキャッシュと呼びます。キャッシュなので2度目以降は高速にアクセスされますが、支店から見て本店がネットワーク的に遠い場合、1度目は遅くなる可能性があります。（下の図における赤点線）
relcache_query_target
そこで導入されたのが新しいパラメータrelcache_query_targetです。このパラメータは、リレーションキャッシュの取得先を指定します。デフォルトの値はmasterで従来と同じくプライマリサーバにアクセスします。スタンバイサーバ側のPgpool-IIの設定でこの値をload_balance_nodeとすると、負荷分散用のサーバにアクセスするようになります。更にこのときプライマリサーバの負荷分散の重みを0にしておけば、常にリレーションキャッシュの問い合わせは支店側のスタンバイサーバに送られるようになります。（下図参照）これで支店の社員も快適にPostgreSQLデータベースにアクセスできるようになります。
レプリケーションの遅延に注意
ただし、relcache_query_targetをload_balanace_modeにした場合、注意すべきこともあります。たとえば新しいテーブルを作成した直後にそのテーブルに問い合わせを発行し、Pgpool-IIがスタンバイサーバ側のシステムカタログを検索した時に、レプリケーションの遅延によってスタンバイサーバ側のシステムカタログにそのテーブルの情報が到達していないと、その検索が失敗してしまいます。これを防ぐために同期レプリケーションを利用することもできますが、プライマリサーバ側の更新が遅くなります。ですからこの構成は、テーブルの作成が頻繁に行われるようなシステムでは採用が難しいかもしれません。
まとめ
今回はPgpool-II 4.1の新機能として、2拠点に分かれたレプリケーション構成への対応を可能にする新しい設定パラメータrelcache_query_targetをご紹介しました。クラウドが活用される時代においては、物理的に店舗が遠隔地に分かれていなくても、クラウドサービスのリージョンを2つ用意して万が一に備えることも珍しくなくなってきました。こうした構成においてもPgpool-IIが活用しやすくなったのではないかと思います。