ウォームスタンバイとは、同じ構成のマシンを2系統（稼働系と待機系）用意し信頼性を高める手法です。PostgreSQL/PowerGres のウォームスタンバイ構成は、稼働系のアーカイブログ（WALログ）を待機系へ転送し、待機系で逐次適用した状態で障害が発生した時に、稼働系から待機系に切り替えてサービスを継続させる PITR を応用した構成になります。

稼働系の PostgreSQL のアーカイブログ（WALログ）を待機系側へ転送し、通常の PITR と同様に待機系側でリストアします。この時、リストア対象のアーカイブログ（WALログ）が尽きても待機系の PostgreSQL は起動させずに、稼働系側からアーカイブログ（WALログ）が来るまで待機し続けます。

ウォームスタンバイの利点と欠点は以下のとおりです。

ここでは、Linux 2台のマシンで PostgreSQL 8.4 のウォームスタンバイの設定手順を説明します。前提として、稼働系及び待機系にはそれぞれ PostgreSQL 8.4 インストールされた状態にしておきます。PostgreSQL の環境変数についても設定されているものとして、コマンドを実行しています。

異なるマシン上でウォームスタンバイを組む場合、事前にパスフレーズ無しの秘密鍵・公開鍵を使った ssh の認証設定を済ませておきます。パスフレーズ無しにするのはアーカイブログの転送が自動処理で行われる為、対話的な入力ができないからです。Windows の場合、ファイル共有を使うなどアーカイブログを転送する為のファイル転送プログラムを別に入手する必要があります。

1. 待機系に pg_standby をインストールします。

   $ cd <PostgreSQLのソースを展開したディレクトリ>/contrib/pg_standby
   $ make
   $ make install

2. 稼働系にマスタとなるデータクラスタを作成します。

   $ initdb -D <データベースクラスタ> --no-locale --encoding=<任意のデフォルト文字エンコーディング>

   ※待機系では、稼働系のデータベースクラスタをフルバックアップしたものを使用するので、initdb の必要はありません。

3. 待機系で稼働系のアーカイブログを格納するためのディレクトリを作成します。

   $ mkdir <アーカイブログ格納ディレクトリ>

4. 稼働系の postgresql.conf のパラメータを変更します。

   archive_mode = on
   archive_command = 'scp %p <待機系ホスト名[IPアドレス]>:/<3.で待機系に作成した稼働系のアーカイブログ格納ディレクトリ>/%f'

   ※pg_hba.conf、postgresql.conf の listen_addresses など稼働系となるサーバからpostgresユーザでpostgresデータベースに接続できるように設定しておく必要があります。

5. 稼働系の PostgreSQL デーモンの起動

   $ pg_ctl -D <データベースクラスタ> -w start

6. 稼働系のベースバックアップ作成します。

   $ psql -U postgres -c "select pg_start_backup('basebackup.tgz');"
   $ tar zcf basebackup.tgz <データベースクラスタ>
   $ psql -U postgres -c "select pg_stop_backup();"

7. 待機系のデータベースクラスタを作成する為に、稼働系のベースバックアップを待機系にコピーし、待機系で展開します。

   $ scp basebackup.tgz <待機系ホスト>:/<待機系のデータベースクラスタ展開先ディレクトリ>
   $ tar zxf basebackup.tgz
   $ mkdir <待機系のアーカイブログ保存ディレクトリ>

8. 待機系のデータベースクラスタの以下の不要なファイルを削除します。

   postmaster.pid ファイル、pg_xlog 以下のファイル、pg_xlog/archive_status 以下のファイル

   $ rm -f <データベースクラスタ>/postmaster.pid
   $ find <データベースクラスタ>/pg_xlog -type f | xargs rm -f

9. 待機系の postgresql.conf のパラメータを変更します。

   archive_mode = on
   archive_command = 'cp %p <待機系のアーカイブログ格納ディレクトリ>/%f'

   ※待機系のアーカイブログ格納ディレクトリを作成しているのは、障害が起き待機系から稼働系になった時、新たに待機系サーバを作成する際に 6.の手順に戻り待機系の為のベースバックアップが必要となるからです。

10. 待機系のデータベースクラスタに recovery.conf を作成し、以下を設定します。

    restore_command = 'pg_standby -l -t <トリガーファイル名> <稼働系のアーカイブログ保存ディレクトリ> %f %p %r'
    recovery_end_command = 'rm -f <トリガーファイル名>'

11. 待機系の PostgreSQL デーモンの起動

    $ pg_ctl -D <データベースクラスタ> -w start

12. 待機系が正常にリストアしているかログや psql で確認

    psql で待機系に接続すると、

    FATAL:  the database system is starting up

    このように出力され、待機系の PostgreSQL に接続できないことが分かります。

手順 10. のトリガーファイルですが、このファイルが作成されると待機系はリカバリが完了した状態で PostgreSQL が起動します。そのトリガーファイルの場所と名前を指定しているオプションになります。待機系が稼働系として起動すると、データベースクラスタの recovery.conf のファイル名が recovery.done になります。recovery_end_command はリカバリが済んだらトリガーファイルを消すという処理を行っています。待機系が起動すると通常の PostgreSQL として動作します。

このように、ウォームスタンバイは待機系は常にリカバリをしている状態なので、停止時間を最小限に抑えてサービスの継続を続ける事ができます。アプリケーションの接続先を変えるというフェイルオーバ機能は PostgreSQL に存在していないので、他のツールを使う事になります。

通常はこの設定手順のようにして、ウォームスタンバイの設定を行います。しかし、ご覧のように設定がどうしても煩雑になりがちです。また、手順 4. にあるアーカイブログを転送する為のツールが、PostgreSQL の本体以外に必要になってくる点で Linux はともかくとして、Windows では不利です。しかし、PowerGres V7 を使うとこの煩雑さと転送ツール必須という点から一気に開放されます。

PowerGres V7 では、この設定の煩雑さを GUI で直観的に設定が可能で、アーカイブモードを有効にし、稼働系・待機系となるホストアーカイブログ格納ディレクトリを登録するだけで構築が完了します。また、管理ツールの拡張機能によりアーカイブログ転送用の外部ツールを必要としないので、Windows でPowerGres V7 をインストールするとそれだけでウォームスタンバイの構築が可能です。

PowerGres V7 では、ウォームスタンバイ構成に、データベースクライアントが接続するのと同じポートにて libpq プロトコルを使ったファイル転送を使っています。libpq プロトコルとは、PowerGres / PostgreSQL にクライアントが接続するときに使うプロトコルです。待機系内にも一時保管のディレクトリを持ち、稼動系クラッシュ時の WAL 損失を抑えます。

待機系には pg_standby の替わりに、pwg_standby というツールを使用します。pg_standby はディレクトリを監視して、新たな WAL ファイルがあれば、これを待機系のデータベースサーバが読む場所に移動するものですが、pwg_standby は稼動系サーバに SQL を投げて、新たな WAL アーカイブファイルがあるかを確認して、SQL を通して WAL 自体のバイナリデータも受け取ります。

PowerGres V7 にはファイルに対する処理要求を受け付ける SQL から利用できる関数が用意されています。これによってファイルの存在確認、ファイルの削除、ファイル内容の取得などを行います。

これら関数の大部分は PowerGres V7 のベースとなる PostgreSQL 8.4 にも存在しているものですが、バイナリファイルを転送できる関数 pg_read_bin_file() が PowerGres V7 の拡張となります。これらは、データベースクラスタ以下のファイルパスしかアクセスできないようになっているため、ベースバックアップとアーカイブログ（WAL ファイル）の格納場所が、データベースクラスタ内に限定されます。また、これらの関数は管理者権限をもったユーザ（ロール）でしか使用できないようになっているため、ウォームスタンバイ用にも管理者ユーザ postgres を使用しなければなりません。

1. 稼働系のデータベースクラスタ作成する

   「ファイル」から「サーバの登録」を選び、サーバの登録を以下設定値を用いて登録します。

   設定項目	設定値
   ラベル名	warmstamdby1
   データベースクラスタ	C:\pwg7_data
   ポート番号	15432
   文字エンコーディング	UTF8
   スーパーユーザ	postgres

   

   ※既にデータベースクラスタが作成してある場合は、新たに作成しなくて構いません。

2. アーカイブモードとベースバックアップとアーカイブログディレクトリの設定

   「PITR」の「全般」タブから、アーカイブモードを有効し、「ベースバックアップとアーカイブログの格納ディレクトリ」を指定します。「指定世代前以前のファイルを自動的に削除」のチェックは外し、「適用」をクリックし「サービス」の「サービスを開始」をクリックしてください。

   

   設定項目	設定値
   ベースバックアップとアーカイブログディレクトリ	C:\pwg7_data\pg_arch

   ※格納ディレクトリは、必ずデータベースクラスタ直下に作成してください。既にサービスが起動している場合は、設定を有効にするため「サービス」の「サービスの再起動」をクリックし、変更を反映させます。

3. 稼働系のベースバックアップ作成

   「PITR」の「ベースバック」タブにある、「ベースバックアップを作成」をクリックします。

   
4. 稼働系サーバの接続認証設定の変更

   「基本設定」の「接続」から、listen_addressesの値を localhost から * に変更し、適用をクリックします。

   

   待機系サーバからの接続が必要になりますので、postgres データベースへ PostgreSQL スーパユーザ postgres によるパスワード認証接続(md5)として設定します。

   

   「設定」の「接続認証」をクリックして、エントリを追加し、上位へ移動させ「適用」をクリックします。「サービス」の「サービスを再起動」をクリックし、接続設定を有効にします。

5. 待機系サーバの設定

   待機系となるマシンの PowerGres 管理ツールを起動し、「ファイル」から「サーバの登録」をクリックします。次に、「ウォームスタンバイの待機系としてデータベースデータベースクラスタを作成」にチェック入れ、待機系の登録を行います。「ラベル」「ポート」「データベースディレクトリ」を入力します。ここでは、稼働系と同じような以下の設定値にします。

   設定項目	設定値
   ラベル名	warmstamdby2
   データベースクラスタ	C:\pwg7_data
   ポート番号	15432
   稼働系サーバ	<稼働系ホスト名、もしくは IP アドレス>
   ポート	15433
   稼働系サーバ上のベースバックアップが存在するディレクトリ	C:\pwg7_data\pg_arch
   ベースバックアップのダウンロード先ディレクトリ	C:\tmp

   ※「稼動系サーバ」のテキストボックスに稼動系サーバのホスト名、または IP アドレスを入力します。また、「ベースバックアップのダウンロード先ディレクトリ」には、アーカイブログなど待機系の一時的なファイル置き場として利用されるディレクトリを指定します。

   

   「OK」をクリックすると、ベースバックアップを展開し、構築するので多少時間がかかります。待機系の「PowerGres を Windows サービスとしての登録」でサービス登録し、「ウォームスタンバイ開始」をクリックし、リカバリモードで起動させると待機系の設定が終了します。この時点から待機系として動作し、稼働系に切り替えるまでリカバリ動作を続けます。

6. 待機系のステータス画面

   「待機系から稼働系に切り替える」をクリックすると稼働系に切り替える事ができます。

   

気をつけておくべき点として、ウォームスタンバイ構成は他の高可用性クラスタ構成と比べると以下の制限事項があります。

1. 待機系に SQL でアクセスすることはできません（参照アクセスも不可）
2. 自動フェイルオーバーの機能を持ちません

• 「障害を検知して、待機系を起動して、アプリケーションからのサーバ接続先を何らかの方法で切り替える」という機能は別に（pgpool-II 等）用意が必要です

• 32bit、64bit の違いがあると動きませんが、それ以外の OS のエディションの違いなどは問題とならないことが多いです。データベースクラスタの物理バックアップがそのまま使用できるかで確認できます

• archive_timeout 設定（図の青色の矢印部分）により、データが失われるリスクを定量的に限定することが可能です。例えば、10 分に設定すれば、少なくとも障害の 10 分前くらいの状態で、待機系を起動することができると考えられます。

このように PowerGres V7 の管理ツールを使う事で、ある設定を忘れる、権限がないなどの細かなミスから開放され、簡単にウォームスタンバイ構成が構築できたと思います。次の第 4 回では、PowerGres V7 で MeCab と textsearch-ja を使った全文検索の設定をし、全文検索をしてみましょう。