ス名]のペアの種類の数だけをmax_poolに指定しておく必要があります。そのスロットが再利用されます。max_poolのデフォルト値は4です。PostgreSQLへのコネクションが張られる点に注意してください。connection_life_timeコネクションプール中のコネクションの有効期間を秒単位で指定します。指定すると有効期間は無限になります。このパラメータを変更した時には設定ファイルを再読み込みしてください。「;」で区切って列挙します。任意のSQL文を追加しても構いません。ALL'PostgreSQLのバージョンによって使用できるSQLコマンドが違います。各バージョンごとのお勧め設定は以下です(ただし、"ABORT"は必ずコマンドに含めてください)。ない場合には発行されません。このパラメータを変更した時には設定ファイルを再読み込みしてください。コネクションプールモードにおけるフェイルオーバ動作についてrawモードと同様の動作をします。レプリケーションモードレプリケーションを有効にするモードです(設定ファイルの雛形はpgpool.conf-replication)。rawモード、コネクションプールモードに加え、以下を設定します。replication_modeレプリケーションモードで動作させる場合はtrueを指定してください。フォルト値はfalseです。load_balance_modetrueを指定するとレプリケーションモードまたはマスタースレーブモードの際に、SELECT文をロードバランスして検索性能を向上させることができます。デフォルト値はfalseです。replication_stop_on_mismatch各DBノードから送られてくるパケットの種類が不一致になった場合に、DBノードを切り放して縮退運転に入ります。あるケースとしては、replicate_selectが指定されていてSELECTが各DBノードで実行されているときに、検索結果行数が一致しないなど、があります(これに限定されるものではありません。あるDBノードでUPDATEが成功したのに、他のDBノードでは失敗した場合が一例です)。pgpoolはパケットの中身まではチェックしていないので、SELECT結果のデータ内容が異なっていても、縮退は起きないことに注意してください。縮退対象のDBノードは「多数決」で少数派になったものが対象になります。多数決で同票になった場合は、マスタDBノード(DBノード番号がもっともわかいもの)を含むグループが優先され、それ以外のグループに所属するDBノードが切り放しの対象になります。このオプションがfalseの場合は、該当のセッションを強制的に終了するだけに留めます。デフォルト値はfalseです。failover_if_affected_tuples_mismatch各DBノードで実行されたINSERT/UPDATE/DELETEの結果行数が不一致になった場合に、DBノードを切り放して縮退運転に入ります。縮退対象のDBノードは「多数決」で少数派になったものが対象になります。多数決で同票になった場合は、マスタDBノード(DBノード番号がもっともわかいもの)を含むグループが優先され、それ以外のグループに所属するDBノードが切り放しの対象になります。このオプションがfalseの場合は、該当のセッションを強制的に終了するだけに留めます。デフォルト値はfalseです。white_function_listデータベースに対して更新を行なわない関数名をコンマ区切りで指定します。このリストに含まれない関数呼び出しを含むSELECTは、負荷分散の対象とはならず、レプリケーションモードにおいてはすべてのDBノードで実行されます。(マスタースレーブモードにおいては、マスター(primary)DBノードにのみ送信されます)。関数名には正規表現を使うことができます。読み出しのみの関数が"get_"あるいは"select_"で始まるならば、以下のような指定が可能です。'get_.*,select_.*'black_function_listデータベースに対して更新を行なう関数名をコンマ区切りで指定します。このリストに含まれる関数呼び出しを含むSELECTは、負荷分散の対象とはならず、レプリケーションモードにおいてはすべてのDBノードで実行されます。このリストに含まれない関数呼び出しを含むSELECTは、負荷分散の対象となります。関数名には正規表現を使うことができます。読み出しのみの関数が"set_"、"update_"、"delete_"あるいは"insert_"で始まるならば、以下のような指定が可能です。'nextval,setval,set_.*,update_.*,delete_.*,insert_.*'white_function_listとblack_function_listの両方を空以外にすることはできません。どちらか一方のみに関数名を指定します。3.0より前のバージョンでは、固定でnextvalとsetvalが書き込みを行なう関数として認識されていました。それと同じ動作を行なわせるには、以下のようにwhite_function_listとblack_function_listを指定します。'nextval,setval,lastval,currval'上の例では、nextvalとsetvalに加え、lastvalとcurrvalが追加されていることに注意してください。lastvalとcurrvalは書き込みを行う関数ではありませんが、これらの関数が負荷分散されることによって、エラーが発生するのを未然に防ぐことができます。black_function_listに含まれる関数は負荷分散されないからです。文をレプリケーションします。挙動と同じになります。文をマスタのみに送信します。replicate_select、load_balance_mode、SELECT問合わせが明示的なトランザクションブロックの内側にあるかどうかどうかで、レプリケーションモードの動作が変化します。値がDBノードの間で一致しなくなることがあります。クションの並列実行性は犠牲になりますが)。COMMIT;に書き換えなければなりません。TABLE...だけが実行されます)。2.2以降は、テーブルがSERIAL列を持つかどうか自動判別するため、SERIAL列がなければ決してテーブルをロックしません。3.0.4までの3.0シリーズは、対応するシーケンステーブルに対して行ロックをかけることで排他制御を行ないます。それ以前のバージョンと比べると、VACUUM(autovacuumを含む)とのロック競合がなくなるメリットがあります。これは他の問題を引き起こします。トランザクション周回が起きた後、シーケンステーブルに対する行ロックはPostgreSQLの内部エラー(詳細には、トランザクション状態を保持するpg_clogへのアクセスエラー)を起こします。これを防ぐため、PostgreSQLのコア開発者はシーケンステーブルに対する行ロックを許可しないことを決定しました。8.3.16そして8.2.22としてリリースされるでしょう)。3.0.5以降では、新しいPostgreSQLがシーケンステーブルに対するロックを許可しなくなったため、pgpool_catalog.insert_lockテーブルに対して行ロックをかけることで排他制御を行ないます。したがって、pgpool-II経由でアクセスするすべてのデータベースにinsert_lockテーブルをあらかじめ作成しておく必要があります。詳細はinsert_lockテーブルの作成の項目をご覧ください。insert_lockテーブルが存在しない場合は、挿入対象のテーブルに対してロックを行います。2.2と2.3シリーズのinsert_lockと同じ動作です。過去のバージョンと互換性のあるinsert_lockを使用したい場合は、configureスクリプトで設定できます。詳細はconfigureの実行の項目をご覧下さい。細かく制御することもできます。LOCK*/コメントを追加する。3.0以降でも同様)。LOCK*/コメントを追加する。3.0以降でも同様)。insert_lockのデフォルト値はtrueです。blockというようなメッセージが出てしまうためです。このパラメータを変更した時には設定ファイルを再読み込みしてください。このパラメータを変更した時には設定ファイルを再読み込みしてください。ユーザパスワードです。このパラメータを変更した時には設定ファイルを再読み込みしてください。recovery_1st_stage_commandオンラインリカバリ中に起動するコマンド名を指定します。このスクリプトはPostgreSQLのマスタサーバ(プライマリサーバ)が起動します。コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にあるコマンドやスクリプトのみを呼び出します。次の3つの引数を受けとります。トからの接続を制限しません。参照や更新を行うことができます。このパラメータを変更した時には設定ファイルを再読み込みしてください。回目のオンラインリカバリ中に起動するコマンド名を指定します。このスクリプトはPostgreSQLのマスタサーバ(プライマリサーバ)が起動します。コマンドファイルはセキュリティ上の観点からデータベースクラスタ以下にあるコマンドやスクリプトのみを呼び出します。次の3つの引数を受けとります。コマンドを起動しません。コマンドを起動します。このパラメータを変更した時には設定ファイルを再読み込みしてください。recovery_timeoutpgpoolは、オンラインリカバリの際にすべてのクライアントが接続を終了するまで待ちます。recovery_timeoutでその最大待ち時間を指定します。待ち時間がrecovery_timeoutを越えると、オンラインリカバリは中止され、通常の状態に戻ります。アイドル状態のクライアントが自分から切断するのを待ちたくない場合は、client_idle_limit_in_recoveryを利用することもできます。recovery_timeoutは、この他、オンラインリカバリの最後にリカバリ対象のDBノードでpostmasterを起動する際の待ち時間にも利用されます。recovery_timeoutのデフォルト値は90秒です。recovery_timeoutを0としてもタイムアウトが無効になるわけではなく、単に即座にタイムアウトするだけですので注意してください。このパラメータを変更した時には設定ファイルを再読み込みしてください。テージでのみ効力があります。リカバリのセカンドステージの進行が妨害されるのを防ぎます。-1を指定すると、直ちにクライアントへの接続を切断してセカンドステージに入ります。クライアントが忙しく、アイドル状態にならない場合はclient_idle_limit_in_recoveryを設定してもセカンドステージに移行できません。この場合、client_idle_limit_in_recoveryに-1を設定すると、クライアントがビジーであってもただちにクライアントへの接続を切断し、セカンドステージに移行することができます。このパラメータを変更した時には設定ファイルを再読み込みしてください。lobj_lock_tableラージオブジェクトのレプリケーションを行いたいときにロック管理に使うためのテーブル名を指定します。その値+1のIDを使ってlo_create()を呼び出してラージオブジェクトの作成を行います(lo_create()を持たないバージョン8.1より前のPostgreSQLではこの処理は行われません)。この方法により、すべてのDBノードで同じIDを持つラージオブジェクトが作成されることが保証されます。このような処理の対象となるラージオブジェクトの操作は、PostgreSQLのC言語用のAPI(libpq)で言うと、lo_creat()です。lo_creat()と同じ通信プロトコルを使っているので、pgpool-IIの上記の操作の対象になり、ラージオブジェクトのレプリケーションが安全に行われるようになります。上記以外であっても、ラージオブジェクトの作成APIでラージオブジェクトのIDを引数として渡すようになっていないものは間違いなくlo_creat()を使っており、pgpool-IIの上記の操作の対象になると考えて良いでしょう。pgpool-IIの上記処理の対象とならないようなラージオブジェクトの作成処理は以下のものです。作成済でかつすべてのユーザが書き込み可能でなければなりません。そのようなテーブルを作る例を示します。PUBLIC;この操作はpgpool-II経由で接続するすべてのデータベースに対して、あらかじめ実施しておかなければなりません。この操作をtemplate1データベースに対して一度行っておけば、以後作成されるデータベースにはこのテーブルが含まれるようになるので、管理の手間が省けます。(したがって、ラージオブジェクトのレプリケーションは保証されません)。lobj_lock_tableのデフォルト値は空文字です。設定した場合、以下の条件のすべてを満たした時にSELECTなどの問い合わせがロードバランスされます。PostgreSQLのバージョンが7.4以降である問い合わせが明示的なトランクザションブロックの内側にない(つまり、BEGINを発行していない)SELECT文(WITH付も含む。詳細な判定条件をフローチャートにしたものもご覧下さい。...とすることによって、本来負荷分散されたり、マスタのみに送信されるべき問合わせがすべてのバックエンドに送信される(レプリケーションされる)ようになります。副作用がある関数を含む問合わせに対してはこのテクニックが利用できます。コマンドを実行する関係上、正しくロードバランスされない可能性があります。