3.3. Pgpool-IIの設定

3.3.1. pgpool.confの設定

pgpool.confPgpool-IIのメインの設定ファイルです。 Pgpool-IIの起動時には-fオプションでこのファイルのパスを指定する必要があります。 ソースコードからインストールした場合、デフォルトではpgpool.conf$prefix/etc/pgpool.confに配置されます。

Pgpool-IIの動作モードについて設定のサンプルがあります。

表 3-1. pgpool.confのサンプル

動作モード設定ファイル名
ストリーミングレプリケーションモードpgpool.conf.sample-stream
ネイティブレプリケーションモードpgpool.conf.sample-replication
マスタースレーブモードpgpool.conf.sample-master-slave
Rawモードpgpool.conf.sample
ロジカルレプリケーションモードpgpool.conf.sample-logical

これらの設定ファイルはデフォルトのソースコードからのインストールでは/usr/local/etcに配置されています。 これらをpgpool.confとしてコピーして使うことが可能です。 (もしかするとそのためにはroot権限が必要かもしれません。)

# cd /usr/local/etc
# cp pgpool.conf.sample-stream pgpool.conf
    

3.3.2. Pgpool-IIの動作モード

Pgpool-IIにはストリーミングレプリケーションモード、ロジカルレプリケーションモード、マスタースレーブモード(slonyモード)、ネイティブレプリケーションモード、rawモードの5つの動作モードがあります。 いずれのモードにおいても、Pgpool-IIはコネクションプーリング、自動フェイルオーバの機能を提供します。 ストリーミングレプリケーションモードとネイティブレプリケーションモードのときにのみオンラインリカバリが利用可能です。

これらのモードは互いに排他的であり、サーバ起動後は変更することができません。 システム設計の初期の段階でどのモードを使うか決めなければなりません。 どれを使えば良いかわからない場合は、ストリーミングレプリケーションモードを使うことを推奨します。

ストリーミングレプリケーションモードはストリーミングレプリケーションを使用するPostgreSQLサーバと一緒に使うことができます。 このモードでは、PostgreSQLがデータベースを同期する責任を持ちます。 このモードは広く使われており、最も推奨されるPgpool-IIの使用法です。 このモードでは負荷分散が可能です。

ロジカルレプリケーションモードはロジカルレプリケーションを使用するPostgreSQLサーバと一緒に使うことができます。 このモードでは、PostgreSQLがテーブルを同期する責任を持ちます。 このモードでは負荷分散が可能です。 ロジカルレプリケーションは必ずしもすべてのテーブルをレプリケーションしないので、負荷分散させるテーブルがレプリケーションされるようにするのはユーザの責任です。 Pgpool-IIはすべてのテーブルをロードバランスします。 このことは、テーブルがレプリケーションされていない場合には、Pgpool-IIがサブスクライバー側の更新されていない古いテーブルを見てしまうかもしれないことを意味します。

マスタスレーブモード(slonyモード)はSlony-Iを使用するPostgreSQLサーバと一緒に使うことができます。 このモードでは、Slony/PostgreSQLがデータベースを同期する責任を持ちます。 Slonyはストリーミングレプリケーションの登場により廃れつつあるため、Slonyを使う特別な理由が無い限りこのモードの使用を推奨しません。 このモードでは負荷分散が可能です。

ネイティブレプリケーションモードでは、Pgpool-IIがデータベースを同期する責任を持ちます。 このモードの利点は同期が同期的に行われることです。 すなわち、データベースへの書き込みは全てのPostgreSQLサーバが書き込み操作を完了するまで返ってきません。 しかし、PostgreSQL 9.6以降では、ストリーミングレプリケーションでsynchronous_commit = remote_applyと設定することにより、同様の効果が得られます。 ネイティブレプリケーションモードの制限事項を回避できるので、この設定が使える場合には、ネイティブレプリケーションモードではなくてこの設定を使うことをお勧めします。 PostgreSQLはノードをまたがるスナップショット管理を提供しないため、セッションYがノードBでコミットする前に、ノードAでコミットしたデータをセッションXが見ることがあり得ます。 もしセッションXが、そのときノードAで見た見たデータに基づいてノードBのデータを更新しようとすると、ノードAとノードBのデータ一貫性は損なわれるかもしれません。 この問題を回避するには、ユーザは明示的にノードAのデータをロックしなければなりません。 これがストリーミングレプリケーションとsynchronous_commit = remote_applyを使用することをおすすめするもう一つの理由です。

このモードでは負荷分散が可能です。

rawモードでは、Pgpool-IIはデータベースの同期に関しては関与しません。 システム全体に意味の有る動作をさせるのはユーザの責任となります。 このモードでは負荷分散はできません