オンラインリカバリを利用したPostgreSQLのマイナーバージョンアップレプリケーションモードの場合レプリケーションモードでpgpool-IIが動作している場合は、オンラインで各ノードのPostgreSQLをバージョンアップできます。ノードの切り離し時と追加時に、pgpool-IIに接続しているすべてのセッションが切断されるので注意してください。オンラインリカバリが利用できるバージョンアップはマイナーバージョンアップのみで、ダンプ/リストアが不要なリリースに限ります。はじめに、上記の「オンラインリカバリの概要」を参考に各ノードでオンラインリカバリが利用できるように準備します。PostgreSQLのバージョンアップは、マスタ以外のノードから行い、最後にマスタノードをバージョンアップします。そこで、まずバージョンアップを行うマスタ以外の1つのノードのPostgreSQLを停止します。pgpool-IIがPostgreSQLの停止を検知すると、以下のようなログを出力して縮退運転に移行します。その際、pgpool-IIに接続しているすべてのセッションは一旦切断されます。localhost(5433)停止したノードのPostgreSQLをバージョンアップします。バージョンアップは、新しいバージョンのPostgreSQLを古いバージョンのインストール先に上書きしても構いませんが、問題が起きた時に元のバージョンに戻せるようにインストール先を変えておくことをお勧めします。新しいバージョンのPostgreSQLを古いバージョンと別の場所にインストールした場合、リカバリスクリプトを編集することなくそのまま使用するには、シンボリックリンクなどを使用してインストール先のパスを以前と合わせる必要があります。上書きインストールした場合は以下のC言語関数をインストールするまでの操作は不要です。オンラインリカバリが実行できます。古いバージョンのPostgreSQLのインストール先ディレクトリ名を変更します。以下は、PostgreSQLが/usr/local/pgsqlにインストールされていたと仮定した一例です。/usr/local/pgsql-old新しいバージョンのPostgreSQLのインストール先にシンボリックリンクを作成します。これにより、今までどおりのパスで新しいバージョンのPostgreSQLが使用できるようになります。以下は、新しいバージョンのPostgreSQLが/usr/local/pgsql-newにインストールされていると仮定した一例です。/usr/local/pgsqlデータベースクラスタディレクトリがPostgreSQLのインストール先ディレクトリの下位にある場合は、同じパスでデータベースクラスタにアクセスできるようにシンボリックリンクを作成するかコピーします。以下は、シンボリックリンクを作成する例です。/usr/local/pgsql/data新しいバージョンのPostgreSQLに、オンラインリカバリ用の関数を「C言語関数のインストール」を参考にインストールします。オンラインリカバリは、データベースクラスタをコピーしますので、最後のpsqlを使用した関数の作成は不要です。installを実行してください。最後にオンラインリカバリを実行して、1つのノードのバージョンアップが完了します。オンラインリカバリは、pcp_recovery_nodeコマンドを実行するかpgpoolAdminで行います。以上の手順をマスタ以外のノードで繰り返し、最後にマスタノードで行えば、全体のPostgreSQLのマイナーバージョンアップは完了です。Replicationを利用している場合は、オンラインでスタンバイのPostgreSQLをマイナーバージョンアップできます。スタンバイのPostgreSQLをマイナーバージョンアップする手順は、上記のレプリケーションモードの手順と同じです。Replicationでのオンラインリカバリ」を参考にしてください。プライマリのPostgreSQLのマイナーバージョンアップは、オンラインではできません。pgpool-IIの停止が必要になります。プライマリのPostgreSQLもバージョンアップの方法自体は、スタンバイと同様です。プライマリのPostgreSQLのバージョンアップは以下の手順で行います。pg_dumpall)、PITRが使用できます。論理バックアップとPITRの操作は、pgpool-IIを経由せずにPostgreSQLに対して直接行ってください。これは、load_balance_modeやreplicate_selectなどの設定によるバックアップの失敗を避けるためです。レプリケーションモード、マスタースレーブモードレプリケーションモードとマスタースレーブモードでpgpool-IIが動作している場合は、クラスタを構成しているいずれかのノードでバックアップを行います。マスタースレーブモードで非同期のレプリケーションを行っている場合で、かつ、最新のバックアップを取得したい場合は、マスタノードでバックアップしてください。SHAREモードのロックがかかります。FULLなど)は、ロック待ちが発生します。これは、非同期のレプリケーションで、スレーブノードに対してバックアップを行っている場合も、マスタが影響を受けることがありますので注意してください。パラレルモードパラレルモードでpgpool-IIが動作している場合、クラスタ全体のデータが一貫性のある状態でバックアップを取得するには、アプリケーション、またはpgpool-IIの一時的な停止が必要になります。pg_dumpallコマンドを実行します。すべてのノードでダンプが終了したら、アプリケーション、またはpgpool-IIを起動してください。PITRを利用する場合は、まず各ノードのシステムの時刻がほぼ一致していることを確認してください。事前に各ノードでアーカイブログの設定を行い、ベースバックアップを取得します。ベースバックアップが終了したら、アプリケーション、またはpgpool-IIを一時的に停止します。停止後、その時刻と次に起動した時刻を記録します。この一時的な停止によって、クラスタ全体のデータが一貫性のある状態を保った期間ができます。ベースバックアップとアーカイブログを使用して各ノードをリストアする場合は、一時停止期間の真ん中あたりの時刻をrecovery.confのrecovery_target_timeに指定したうえで、リカバリを行ってください。システムDBのバックアップパラレルクエリモード、またはクエリキャッシュを使用している場合は、システムDBもバックアップする必要があります。pgpool.confのsystem_db_dbnameに設定したデータベースをバックアップしてください。pgpool-IIの配置についてpgpool-IIは、独立したサーバに配置することもできますし、アプリケーションサーバと同居させることもできますし、その他の配置も考えられます。ここではそれぞれの配置方法を紹介し、それぞれの特徴、メリット、デメリットを検討します。専用のサーバに配置pgpool-IIを物理的に独立した専用のサーバに配置する方法です。分かりやすい方法ですし、他のサーバソフトウェアの影響を受けないのでpgpool-IIをもっとも安全に運営できますが、サーバ装置を1台余計に増やす必要があるのが欠点です。そのサーバが単一障害点になります(pgpool-IIが単一障害点になることを回避するには、後述のpgpool-HAを併用します)。Webサーバやアプリケーションサーバと同居Apache、JBoss、TomcatなどのWebサーバやアプリケーションサーバが稼働しているサーバにpgpool-IIを同居させる方法です。この方法では、Webサーバやアプリケーションサーバとpgpool-IIの通信がローカルマシン内になるので、ソケット通信がマシン間で通信するよりも高速になるメリットがあります。複数のWebサーバ/アプリケーションサーバがあれば、自然と単一障害点を回避できるようになります。(この場合、複数のpgpool-IIの設定は同じにしてください)。複数のpgpool-IIが動作しているケースでは以下の点に注意してください。pgpool-IIとDBサーバの間のネットワークが不安定だと、pgpool-IIから見てDBノード#1がダウン、他のpgpool-IIから見て正常、というような状態になってしまうことがあります。ネットワークを二重化するなどして、ネットワーク障害が起きないようにしてください。レプリケーションモードで、オンラインリカバリ実行中は、一つのpgpool-IIだけ残して他のpgpool-IIを落してください。ないと、リカバリ後の結果に整合性がなくなる可能性があります。Replicationモードでは、同時に複数のpgpool-IIでオンラインリカバリを実行しない限り、問題ありません。DBサーバと同居PostgreSQLの稼働しているDBサバと同居させる方法です。この方法では、pgpool-IIが単一障害点になることがなく、余計なサーバを追加する必要もない点が優れていますが、アプリケーションがどのDBサーバに接続するのかを自ら判断する必要があるのが欠点です。この問題を解決するには、pgpool-HAと組み合わせて仮想IPを利用します。pgpool-HAについてpgpool-HAは、heartbeatなどを利用してpgpool-IIを二重化し、pgpool-II自体の可用性を上げるソフトウェアです。pgpool-IIと同様、pgpoolプロジェクトのサブプロジェクトであり、pgpoolの開発サイトでOSSとして公開されています。トラブルシューティングこの章では、pgpool-IIを運用中に直面しやすい障害と、その対策方法をケース別に説明します。failedヘルスチェックでpgpool-IIがDBノードの障害を検出しました。foo)がダウンして切り離され、新しくDBノード0がマスタとして扱われ出したことを示しています。DBノード1をチェックし、異常原因を取り除いた後に、可能であればオンラインリカバリ機能を使ってDBノード1を復帰させてください。exitedpgpool-IIから見てクライアントが突然セッションを切断した際にこのようなログが残ります。原因としては、アプリケーションのバグ、アプリケーションが強制終了された、やネットワークの一時的な障害が考えられます。継続してこのログが出力されるようであれば、アプリケーションやネットワークの障害を調査することをおすすめします。mismatchエラーレプリケーションモードで運用している場合に出ることがあるエラーです。exist]pgpool-IIは、SQLコマンドを各DBノードに送信したら、各DBノードから同じレスポンスが返ってくることを期待します。このエラーは、異なるレスポンスが返ってきたことを示します。was:のあとに、このエラーを返す原因となった問い合わせのSQL文が表示されます。そのあとで、各DBノードからのレスポンスの種類と、レスポンスがエラーの場合は、PostgreSQLのエラーメッセージが表示されます。exist」であったことがわかります。このエラーは、マスタースレーブモードでも出ることがあります。SETコマンドは、各セッションの状態を同じにするために、基本的にすべてのDBノードに送信されるからです。データベースを調べて原因を特定し、もしDBの同期が崩れているようであれば、オンラインリカバリを使って正しいデータと同期させてください。tuplesレプリケーションモードにおいて、pgpool-IIが、DBノード間でINSERT/UPDATE/DELETEが返す結果行の違いを検出しました。1によって更新された行数が、DBノードで異なっています。次の行では、DBノード1を切り離したこと、更にDBノード0での結果行数が0だったのに対して、DBノード1では、1行だったことを表しています。正しくないデータを持っていると思われるDBノードを停止し、オンラインリカバリを使って正しいデータと同期させてください。制限事項PostgreSQLの機能pg_terminate_backend()でバックエンドを終了させるとフェイルオーバしてしまいます。これは、PostgreSQLがpostmasterをシャットダウンしたときと同じメッセージをpgpoolに送るためです。今のところ対応方法はないので、この関数を使わないようにしてください。認証方式だけが利用できます。crypt認証は利用できません。md5認証に関しては、PostgreSQLに該当ユーザをmd5認証付でPostgreSQLに登録し、次にpgpoolに付属するpg_md5コマンドを使って、pool_passwdという認証ファイルを作成することにより利用できるようになります。md5により暗号化されたユーザ名とパスワードがpool_passwdに登録されます。pool_passwdがまだ存在しなければ、pgpool.confと同じディレクトリ内に作成されます。pool_passwdのフォーマットは、"ユーザ名:パスワード"となっています。pool_hba.confにmd5認証のエントリを作成します。pool_passwdに登録するパスワードは、PostgreSQLに登録したパスワードと完全に同じでなければなりません。md5認証方式だけが利用できます。一時テーブルの扱い制限対象:マスタースレーブモード一時テーブルの作成、更新は常にマスタ(primary)で行なわれます。3.0以降では、マスタで行なわれるので、一時テーブルを使っているかどうかを意識する必要はありません。文字列として一時テーブル名をSELECTの中で使っている場合は一時テーブルかどうかの確認のしようがないので、負荷分散されてしまい、その一時テーブルが見つからないか、もしくは同じ名前の別のテーブルを検索してしまうことになります。ALNCE*/のコメントを挿入してください。3.0以降ではマスタで検索が行なわれるので、問題になりません。システムカタログへの検索は常にマスタで行なわれるからです。ンはしますが、2台のホストでまったく同じ値がコピーされる保証はありません。シリアル型に関しては、insert_lockを有効にしておけばテーブルロックを利用して同期が取られます。nextval()で呼び出している場合は自動的にレプリケーションされるので同期が取れます。now()は、自動的にマスタ側から取得した時刻値に置き換えることによってレプリケーションできるようになっています。以下の点に注意してください。3.1より前のバージョンではDEFAULTにタイムスタンプを返す式が含まれているかどうかの判定は正確ではありません。1)のようなものも現在のタイムスタンプとして書き換えを行います。3.1以降では、拡張プロトコルとPREPARE以外の場合にこの点が改善されており、上記の例にあるような例も正しく処理されます(つまり、デフォルト値として明日の日付がセットされます)。SELECTでは、列のDEFAULTに対する書き換えを行いません。1は書き換えられません。ンを終了しても削除されません。DROPをお使い下さい。ALLを指定すれば自動的に削除されるので問題ありません。扱うことができないクエリについて説明します。マルチバイト文字について制限対象:全モード現在の実装では、マルチバイト文字の変換処理を行いません。サーバエンコーディングを一致させるようにしてください。処理することができません。文を分けて送信してください。送信するので、実際には問題になりません。ドライバなどのような拡張問い合わせプロトコルには対応していません。簡易問い合わせプロトコルを使用してください。(デフォルト値)に設定してください。