マスタースレーブモードこのモードはPgpool-IIと(Slony-Iやストリーミングレプリケーションのような)他のマスター/スレーブ型のレプリケーションソフトウェアと組み合わせるのに使用されます。実際にデータレプリケーションを行うのはこれらのソフトウェアに任されます。スレーブノードの数は1つに限定されず、Pgpool-IIは127個までのスレーブノードを持つことができます。マスタースレーブモードは、スレーブノードが1つも存在しない場合マスターノードのみを動作させることができます。参照負荷をスタンバイバックエンドノードに振り分ける負荷分散(項5.7を参照)もマスタースレーブモードと共に使用可能です。マスタースレーブモードでは以下のオプションを設定する必要があります。(boolean)マスタースレーブモードを有効にします。デフォルトはoffです。master_slave_modeとreplication_modeは相互に排他的で、一度に一方しか有効にすることができません。このパラメータはサーバ起動時にのみ設定可能です。(enum)PostgreSQLノード間のデータレプリケーションに用いる外部のレプリケーションシステムを指定します。以下の表にこのパラメータで有効な値のリストを示します。PostgreSQLの組み込みレプリケーションシステム(ロジカルレプリケーション)に適合デフォルトは'stream'です。このパラメータはサーバ起動時にのみ設定可能です。レプリケーションモードこのモードではPostgreSQL間のデータレプリケーションをPgpool-IIに行わせます。参照負荷をスタンバイバックエンドノードに振り分ける負荷分散(項5.7を参照)もレプリケーションモードと共に使用可能です。以下のオプションがレプリケーションモードにおけるPgpool-IIの動作に影響します。(boolean)レプリケーションモードを有効にします。デフォルトはoffです。replication_modeとmaster_slave_modeは相互に排他的で、一度に一方しか有効にすることができません。このパラメータはサーバ起動時にのみ設定可能です。(boolean)これがonで、全てのPostgreSQLバックエンドノードに送られたクエリに対して、全てのノードが同じパケット種類で応答しなかった場合、多数派とは異なる応答したバックエンドノードはPgpool-IIにより切り離されます。replication_stop_on_mismatchがoffの場合に同様の状況が発生したときには、Pgpool-IIは現在のユーザセッションを強制終了するだけにとどめ、バックエンドの切り離しは行いません。Pgpool-IIはバックエンドから返されたデータは調べずに、結果パケットの種類の比較のみにより決断します。replication_stop_on_mismatchを有効にする典型的なユースケースは、バックエンドノード間のデータ不整合の防止です。UPDATE文が他のノードでは成功しているのにあるバックエンドノードでは失敗した場合、そのバックエンドノードを切り離したいかもしれません。デフォルトはoffです。このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。(boolean)これがonで、全てのノードの応答でINSERT/UPDATE/DELETEクエリの影響を受けたタプルの数が同じでなかった場合、多数派とは異なる応答したバックエンドノードはPgpool-IIによる切り離されます。failover_if_affected_tuples_mismatchがoffの場合に同様の状況が発生したときには、Pgpool-IIは現在のユーザセッションを強制終了するだけにとどめ、バックエンドの切り離しは行いません。同票で、2つ以上のグループで同じノード数だった場合は、マスターノード(最も若いDBノード番号のバックエンドノード)を含むグループが優先されます。デフォルトはoffです。このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。(boolean)onを設定すると、Pgpool-IIはSELECTクエリのレプリケーションモードを有効にします。SELECTクエリが全てのバックエンドノードに送信されます。Mデフォルトはoffです。このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。(boolean)onに設定すると、Pgpool-IIはINSERT文が発行される前にPostgreSQL上のテーブルを自動的にロックします。SERIAL型を使っているテーブルをレプリケーションすると、SERIAL型の列の値がDBノードの間で一致しなくなることがあります。この問題の回避策は、INSERT実行前に該当テーブルを明示的にロックすることです。テーブルの自動ロックのため、Pgpool-IIは以下の変換を行います。...これを次のように変換します。COMMIT;注意この方法はトランザクションの並列実行性を大きく劣化させます。V2.2以降では、テーブルがSERIAL列を持つかどうか自動判別するため、SERIAL列がなければ決してテーブルをロックしません。V3.0では、テーブルロックではなくシーケンステーブルに対して行ロックをかけます。これはVACUUM(autovacuumを含む)とのロック競合を最小化することを意図しています。これは他の問題を引き起こします。(詳細には、トランザクション状態を保持するpg_clogへのアクセスエラー)を起こします。これを防ぐため、PostgreSQLのコア開発者はシーケンステーブルに対する行ロックを許可しないことを決定しました。8.3.16そして8.2.22としてリリースされました)。V3.0.5以降では、新しいPostgreSQLがシーケンステーブルに対するロックを許可しなくなったため、pgpool_catalog.insert_lockテーブルに対して行ロックをかけます。したがって、Pgpool-II経由でアクセスするすべてのデータベースにinsert_lockテーブルをあらかじめ作成しておく必要があります。詳細は項2.7をご覧ください。insert_lockテーブルが存在しない場合は、挿入対象のテーブルに対してロックを行います。V2.2とV2.3シリーズと同じ動作です。過去のバージョンと互換性のあるinsert_lockを使用したい場合は、configureスクリプトでロック方法を指定できます。詳細は項2.4をご覧下さい。LOCK*/コメントを追加します。LOCK*/コメントを追加します。alter_tableがfailします。その理由は、ruleテストでPgpool-IIがビューにLOCKを実行しようとするため、そして以下のエラーメッセージが出てしまうためです。blockたとえば、transactionsテストでは、存在しないテーブルに対してINSERTを試みており、Pgpool-IIはPostgerSQLにそのテーブルのロックを獲得させることになります。これはもちろんエラーとなります。トランザクションがアボート状態になり、続くINSERTでは上記エラーが出てしまいます。デフォルトはoffです。このパラメータはPgpool-IIの設定を再読み込みすることで変更可能です。(string)ラージオブジェクトのレプリケーションを行いたいときにロック管理に使うためのテーブル名を指定します。このテーブルが指定されている場合、Pgpool-IIは、lobj_lock_tableで指定されているテーブルをロックした後、pg_largeobjectシステムカタログを参照してラージオブジェクトIDを生成し、lo_create()を呼び出してラージオブジェクトの作成を行います。この方法により、レプリケーションモードにおいてPgpool-IIが全てのDBノードで同じラージオブジェクトIDを得られることが保証されます。8.0以前のバージョンではこの処理は行われません。libpqの関数lo_creat()の呼び出しがこの機能の契機となります。API(pg_lo_create、またはPDOといったPHPライブラリの同様のAPI)、様々なプログラミング言語の同様のAPIを経由したラージオブジェクトの生成においても同じプロトコルが使われることがわかっているので、この機能は動作するはずです。この機能はラージオブジェクトに対する以下の操作では動作しません。lo_create、lo_import_with_oidを使う全てのAPI。全てのPostgreSQLユーザはlobj_lock_tableへ書き込み可能である必要が有ります。これはどのスキーマに作成されてもかまいません。ラージオブジェクトロックテーブルを作る例を示します。PUBLIC;デフォルトは''(空文字列)で、この機能は無効です。