意図的に構文エラーを起すSQLを送信することによって、トランザクションをアボートさせます。trueならば、フェイルオーバが起きます。その際、以下のようなエラーメッセージが表示されます。nodeログには更に以下のように、更新行数が記録されます(この場合はDBノード0が0行、DBノード1が1行)。Replicationのような、master/slave式のレプリケーションソフトにレプリケーションをまかせるモードです。それにオンラインリカバリが必要ならばbackend_data_directory)をセットし、master_slave_modeとload_balance_modeをtrueにします。pgpool-IIは、レプリケーションされる必要のある問い合わせはマスターに送り、その他の問い合わせを可能ならば負荷分散します。問い合わせによってマスターDBだけに問い合わせが送られる場合と、DBノードの間でロードバランスされて問い合わせが送られる場合があります。マスタスレーブモードでは、一時テーブルの作成、更新、検索はマスタノードでのみ実行されます。SELECTをマスタだけで実行するように強制することができます。コメントをSELECTに前に挿入しなければなりません。trueにします(同時にtrueにはできません)。'master_slave_sub_mode'を指定します。これは、'slony'(デフォルト)か、'stream'です。'slony'はSlony-Iを利用する時に指定します。Replicationを利用するときに指定します。Slony-Iを使う場合の設定ファイルの雛形はpgpool.conf.sample-master-slaveです。Replicationを使う場合の雛形はpgpool.conf.sample-streamです。マスタースレーブモードでも、DB書き込みを行なう関数の呼び出しを含むSELECTを負荷分散の対象から外す指定をwhite_function_listとblack_function_listで行なうことができます。詳細はwhite_function_listの項をご覧下さい。Standbyを併用することを前提にしています)。このモードでは、以下の設定項目も利用できます。delay_thresholdスタンバイサーバへのレプリケーションの遅延許容度をバイト単位で指定します。負荷分散が有効であってもそのDBノードにSELECTを送信せず、プライマリサーバに送るようにします。delay_thresholdが0の場合は、遅延のチェックを行ないません。delay_thresholdが指定されていても、sr_check_periodが無効(=0)ならば、やはりこの機能は働きません。デフォルト値は0です。このパラメータは設定ファイルの再読込によって変更できます。sr_check_periodストリーミングレプリケーションの遅延チェックの間隔を秒単位で指定します。デフォルト値は0で、これはチェックを行わないことを意味します。このパラメータは設定ファイルの再読込によって変更できます。sr_check_userストリーミングレプリケーションの遅延チェックを行うユーザ名を指定します。このユーザは、すべてのバックエンドに存在しなければなりません。なければエラーになります。PostgreSQLバックエンドに関数呼び出しのリクエストを送ります。sr_check_userとsr_check_passwordが使われるからです。このパラメータは設定ファイルの再読込によって変更できます。sr_check_passwordストリーミングレプリケーションの遅延チェックを行うユーザに対するパスワードをを指定します。パスワードが必要なければ空文字('')を指定します。このパラメータは設定ファイルの再読込によって変更できます。log_standby_delayレプリケーションの遅延状況をログする条件を指定します。'none'を指定すると、ログを出力しません。'always'ならヘルスチェックを実行するたびに必ず出力します。'if_over_threshold'を指定すると、delay_thresholdを超えたときだけログが出力されます。デフォルト値は'none'です。このパラメータは設定ファイルの再読込によって変更できます。コマンドでも確認できます。項目名は"standby_delay#"です(#はDBノードIDです)。replicationを利用したマスタスレーブモードでは、PrimaryやStandbyノードが停止した場合に、レプリケーションモードと同じように自動フェイルオーバを行なわせることができます。「トリガファイル」を作成することにより、Standbyノードを、リカバリモードから更新問い合わせを受け付ける通常のPostgreSQLの動作モードに自動変更することができます。これを利用して、フェイルオーバコマンドを併用して、Primaryノードがダウンしたときに、Standbyノードが自動的にとって代るような設定を行なうことができます。複数のStandbyノードを利用している場合、この設定を行なうときは、delay_thresholdを設定して、他のStandbyに振り分けられたSELECTが古いデータを取得しないようにしておくことをお勧めします。1台目のStandbyノードがPrimaryにとって代ったのちにダウンしてしまったケースで、2台目のStandbyが更に取って代わるとデータに不整合がおきるので、そのような設定は行なわないようにしてください。フェイルオーバの設定手順を示します。フェイルオーバ用のスクリプトを適当な場所(ここでは/usr/local/pgsql/bin)に配置して、実行権限を与えておきます。failover_stream.shpgpool.confの、failover_commmandを設定します。/tmp/trigger_file0'standbyノードのrecovery.confを設定します。PostgreSQLのインストールディレクトリ下の"share/recovery.conf.sample"にあります。これをstanndbyノードのデータベースクラスタ下に"recovery.conf"としてコピーしておきます。以下の項目を設定します。'/tmp/trigger_file0'primaryノードのpostgresql.confを設定します。以下は例ですので、必ず実際に合わせて調整してください。1primaryノードのpg_hba.confを設定します。以下は例ですので、必ず実際に合わせて調整してください。replicationが開始されます。primaryノードがダウンしたときに、自動的にstandbyノードが通常のPostgreSQLとして立ち上がり、更新問い合わせを受け付けるようになります。Standbyを利用している環境では、primaryノードに送ってよい問い合わせ、standbyに送ってもよい問い合わせ、両方に送らなければならない問い合わせを厳密に管理する必要があります。Replicationモードは、こうした振り分けを自動的に行ないます。ここでは、そのロジックについて説明します。問い合わせの種類によって以下のように分けられます。off二相コミット関連のコマンド。NOTIFYVACUUMシーケンス関連の関数(nextvalやsetvalなど)の呼び出し。ラージオブジェクトの生成Primary/Standbyどちらにも送ることのできる問い合わせ。負荷分散設定が有効ならば、standbyノードにも送信されます。レプリケーションの遅延がdelay_thresholdを上回っている場合は問い合わせはPrimaryに送られます。ALL明示的なトランザクションでは、以下のようになります。BEGINなどのトランザクション開始コマンドは、Primaryサーバに送られます。続くSELECTなど、Primary/Standbyどちらにも送ることのできる問い合わせは、Primaryのトランザクション内でそのまま実行されるか、Standbyサーバで実行されます。INSERTなど、Standbyに送ることのできない問い合わせが現われた場合は、Primaryサーバで実行されます。以後、SELECTなど、本来Standbyに送信しても構わないコマンドもPrimaryサーバで実行されます。これは、トランザクションの中で実行されたINSERTなどの問い合わせの結果をSELECTが直ちに参照できるようにするためです。この状態は、トランザクションが閉じるか、アボートするまで続きます。問い合わせが、拡張問い合わせモードで実行される場合は、問い合わせのparse段階で、問い合わせが負荷分散可能かどうかで送信先が決まります。その際の判断ルールは、通常のSQLと同じです。問い合わせがINSERTならば、Primaryサーバで実行される、という具合です。executeも同じDBノードで実行されます。parseが実行されてから更新クエリが来た場合は、そのSELECTはPrimaryノードで実行されなければなりません。そのため、同じSELECTが再度Primaryノードでパースされることになります。]最後に、pgpool-IIのパーサが構文エラーと判断した問い合わせはPrimaryノードだけに送られます。replicationを利用したマスタスレーブモードでは、レプリケーションモードと同じようにオンラインリカバリが利用できます。primaryサーバをマスタとし、standbyサーバをリカバリします。primaryサーバが停止している状態ではオンラインリカバリはできません。primaryサーガ停止している状態からの復旧は、すべてのDBノードとpgpool-IIを停止させて手動で実施しなければなりません。通常、postgresユーザとなります。DBにログインするときに使うパスワードです。ここで指定するファイルは、primaryサーバからベースバックアップを取得し、standbyサーバにリストアするものでなければなりません。primaryのPostgreSQLから、recovery_userの権限で起動され、その時に引数を受けとります。詳細は、recovery_1st_stage_commandの設定項目をご覧ください。このスクリプトファイルは、primaryのデータベースクラスタ下に配置し、実行権限を与えておきます。サンプルとして、primary/standbyそれぞれ一台構成の場合のスクリプト(basebackup.sh)を示します。パスワードなしでリカバリ対象のstandbyノードにログインできることを前提にしているので、あらかじめsshの設定を行なっておく必要があります。空のままで構いません。言語関数やSQL関数を各DBノードにインストールします。template1オンラインリカバリが終了したあと、pgpool-IIは、停止していたDBノードのPostgreSQLを起動します。そのためのスクリプトを、各DBノードのDBクラスタにインストールします。スクリプトのサンプルがソースコードの"sample"ディレクトリに含まれているので、それを利用してください。このサンプルの中では、PostgreSQLの起動をpg_ctlコマンドで行っており、pg_ctlコマンドへのパスが記述されています。デフォルトでは/usr/local/pgsql/bin/pg_ctlとなっているので、お使いの環境に合わせて修正してください。このスクリプトはsshを使用しますので、少くとも、primaryのDBノードから、standbyのDBノードに対して、recovery_userでパスワードなしでsshが利用できることが必要です。必要ならばあらかじめ設定しておいてください。以上でオンラインリカバリの設定が終了しました。standbyノードを停止した状態で、pcp_recovery_nodeを利用するか、pgpoolAdminの「リカバリ」ボタンでオンラインリカバリが出来るようになったはずです。うまくいかない場合は、pgpool-IIのログ、primaryサーバ、standbyサーバのログを確認してください。参考までに、ストリーミングレプリケーションでのオンラインリカバリの内部処理の流れを説明します。指定されたスクリプトを実行します。PostgreSQLは、データベースクラスタディレクトリ中で関数を実行します。よって、pgpool_recovery関数もprimaryサーバのデータベースクラスタディレクトリ中で関数を実行されることに注意してください。primaryサーバで、pgpool_remote_start関数を実行します。この関数は、primaryサーバのデータベースクラスタディレクトリ中にあるpgpool_remote_startという名前のスクリプトを起動し、ここからssh経由でリカバリ対象のstandbyサーバのPostgreSQLをpg_ctlコマンドを使って起動します。起動はバックグラウンドで行われ、起動できたかどうかは次のステップで確認されます。template1データベースに接続を試みます。リトライは、recovery_timeout秒間行われます。PostgreSQLの起動に成功したら、次のステップに移ります。failback_commandが空でない場合は、pgpool-IIの親プロセスは指定されたスクリプトを起動します。failback_commandが終了したら、pgpool-IIの子プロセスをすべて再起動します。パラレルモードパラレルクエリ機能が利用できるモードです。持たせることができます。