ホットスタンバイは、負荷分散により性能を向上させ、障害発生時のダウンタイムを最小限に留める手法の一つです。 PowerGres を 2 系統用意してそれぞれを稼動系、待機系サーバとし、稼動系サーバではデータの更新と参照を受け付け、待機系サーバではデータの参照のみを受け付けます。
待機系サーバがデータの更新、参照ともに受け付けずに障害発生に備えて待機しているだけのウォームスタンバイに対して、待機系サーバがデータの参照を受け付けることができるというからホットスタンバイと呼ばれます。
ホットスタンバイでは、正常時は稼動系と待機系サーバに参照を振り分けて性能を向上させ、障害発生時はサーバを切り替えることで耐障害性を向上させることができます。
PowerGres はこれを実現するために、待機系サーバは、稼動系サーバから定期的にデータ更新の差分をダウンロードして適用します。 これをストリーミングレプリケーションと呼びます。 ストリーミングレプリケーションでは、データ更新の差分をトランザクションログのレコード単位で適用します。 更新内容の反映は非同期で行われますが、通常、待機系サーバのリソースが十分であれば遅延は 1 秒以内に収まります。
稼動系と待機系サーバの PowerGresは、同一プラットフォームかつ同一バージョンである必要があります。
注意
稼動系から待機系サーバへのフェイルオーバや参照の負荷分散は、自動では行われません。 アプリケーション側の作り込みで対応するか、pgpool-II などのミドルウェアを導入する必要があります。
待機系サーバは常にリカバリを実施しているため、データの参照しか行うことができません。更新はエラーになります。 待機系サーバで実行可能な SQL は「PostgreSQL ドキュメント」の「25.5. ホットスタンバイ」を参照してください。
稼動系サーバの障害発生時に待機系サーバへのフェイルオーバを行った場合は、待機系サーバに未反映の更新内容は失われますのでご注意ください。
稼働系サーバのアーカイブログは自動的には削除されません。アーカイブログが溜りつづける現象を回避するには、以下のようなバッチファイルやシェルスクリプトを作成して定期的に実行するようにします。
Windowsの場合
@echo off
rem # WALファイル保存ディレクトリ
set xlogpath=C:\pg_data\pg_archive
rem # 残すファイル数
set restfile=10
cd %xlogpath%
for /f "skip=10" %%A in ('dir /b /o-n ^| find /v "archive" ^| ^
find /v "backup"') do (
del %%A
)
Linuxの場合
#!/bin/sh
# WALファイル保存ディレクトリ
xlogpath=/opt/pg_data/pg_archive
# 残すファイル数
restfile=10
cd $xlogpath
ls -t | grep -v backup | grep -v archive_status | \
sed -e "1,${restfile}d"| xargs rm -f
ホットスタンバイを構築するには、まず、稼動系サーバを設定するサーバ上で PowerGres Manager を起動して以下の手順に従って設定を行います。
サーバの登録が完了していない場合には、「サーバ」の「1. サーバの登録」を参照してデータベースクラスタを作成し、「サービス」の「1. サービスの開始」を参照してサービスを開始してください。
ホットスタンバイ構築ウィザードの指示に従って稼動系サーバの設定を行っていきます。
複数の待機系サーバを設定する場合や、今後、待機系サーバの数を増やすことを計画している場合には、その数に応じて待機系サーバの数を入力してください。 待機系サーバの数は後から変更することもできますが、変更を反映するにはサービスの再起動が必要になります。
待機系サーバの数をホットスタンバイ構築ウィザードの終了後に変更する場合には、稼動系サーバで、サーバ管理ツリーメニューの「設定」から「基本 (postgresql.conf)」を選択し、「WAL」カテゴリ内の「ストリーミングレプリケーション」を開き、「max_wal_senders」パラメータの値を変更します。 その後、稼動系サーバ、待機系サーバの順にサービスを再起動します。
ヒント
パラメータの設定について詳しくは、「設定」の「1. 基本 (postgresql.conf)」を参照してください。
ホットスタンバイでは、稼動系サーバでのデータ更新の差分を待機系サーバに適用してレプリケーションを行うため、待機系サーバから稼動系サーバへの接続が行われます。 そこで、稼動系サーバで、待機系サーバからの接続を受け付けるようにクライアント認証の設定を行います。
ホットスタンバイ構築ウィザードでは、レプリケーション用のスーパーユーザ「repli」が特定の IP アドレスから接続した場合にパスワード認証を行うように設定します。 repli ユーザが存在しない場合には自動的に作成されます。
『パスワード』、『パスワード (再確認)』には、 repli ユーザのパスワードを入力します。 repli ユーザのパスワードは待機系サーバの設定時に必要になります。
『IP アドレスの範囲』には、稼動系サーバへの接続を受け付ける IP アドレスの範囲を CIDR 形式 (例: 192.0.2.0/24) で入力します。 「samenet」と入力すると、稼動系サーバのサブネット内からの接続を受け付けます。
レプリケーション用のクライアント認証をホットスタンバイ構築ウィザードの終了後に設定する場合には、サーバ管理ツリーメニューの「設定」から「接続認証 (pg_hba.conf)」を選択し、データベース名にレプリケーションを表す replication と指定して設定を行います。
クライアント認証の設定について詳しくは、「設定」の「2. 接続認証 (pg_hba.conf)」を参照してください。
これで稼動系サーバの設定は完了です。 続いて、待機系サーバの設定を行います。
稼動系サーバの設定が完了したら、続いて、待機系サーバを設定するサーバ上で PowerGres Manager を起動して以下の手順に従って設定を行います。
ホットスタンバイ構築ウィザードの指示に従って待機系サーバの設定を行っていきます。
待機系サーバは、稼動系サーバからデータをダウンロードして設定するため、あらかじめサーバの登録やサービスの開始を行う必要はありません。
待機サーバの『ラベル』、『ポート』、『データディレクトリ』には、稼働系サーバからデータをダウンロードして待機系サーバとして登録するための情報を入力します。 それぞれの情報はサーバの登録時に入力するものと同じ意味になります。 サーバの登録について詳しくは、「サーバ」の「1. サーバの登録」を参照してください。
『作業ディレクトリ』には、稼動系サーバからダウンロードしたデータを一時的に保存するディレクトリを指定します。 少なくとも稼動系サーバのデータベースディレクトリが収まる程度のディスクの空き容量が必要となります。
Windows版では、稼働系サーバからダウンロードできるサイズは、2GB までです。ベースバックアップのサイズが 2GB 以上ある場合には、手動で「作業ディレクトリ」内にベースバックアップファイルをコピーしておく必要があります。
稼動系サーバの『ホスト』、『ポート』には、稼動系サーバのホスト名、ポート番号を入力します。 ホスト名は IP アドレスでなくても問題ありません。
『パスワード』には、レプリケーション用のスーパーユーザ「repli」のパスワードを入力します。 ここで入力するパスワードは稼動系サーバの設定時に入力したものです。
これで待機系サーバの設定は完了です。 続いて、待機系サーバのサービスを開始します。
Windows の場合には、まず、『PowerGres を Windows サービスとして登録』ボタンをクリックし、待機系サーバを Windows サービスとして登録する必要があります。
待機系サーバの設定が正常に完了していれば、『サービスを起動』ボタンの代わりに『スタンバイ開始』ボタンが表示されます。
画面下のサーバ状態に「サーバ ラベル名 (localhost:ポート番号) はスタンバイ中です。」と表示されていれば、待機系サーバとして正常にサービスが開始されています。
ホットスタンバイの構築が完了したら、以下の手順に従ってホットスタンバイが正常に動作していることを確認します (任意)。
稼動系サーバでデータの更新を行います。
=# CREATE TABLE t (c int);
CREATE TABLE
=# \d t
Table "public.t"
Column | Type | Modifiers
--------+---------+-----------
c | integer |
=# INSERT INTO t VALUES (1);
INSERT 0 1
=# SELECT * FROM t; c --- 1 (1 row)
稼動系サーバに対するデータの更新が待機系サーバに反映されていることを確認します。
=# \d t
Table "public.t"
Column | Type | Modifiers
--------+---------+-----------
c | integer |
=# SELECT * FROM t;
c
---
1
(1 row)
=# INSERT INTO t VALUES (2); ERROR: cannot execute INSERT in a read-only transaction
稼動系サーバに障害が発生して停止した場合でも、待機系サーバではデータの参照のみを受け付けることができます。 データの参照のみでなく更新も受け付けるには、障害の発生した稼動系サーバを復旧させるか、待機系サーバを稼動系に切り替える必要があります。 待機系サーバを稼動系に切り替えることをフェイルオーバと呼びます。
待機系サーバを稼動系に切り替えた場合には、待機系サーバに未反映のデータ更新は失われます。
待機系サーバを稼動系に切り替えるには、以下の手順に従って操作を行います。
画面下のサーバ状態に「サーバ ラベル名 (localhost:ポート番号) は稼働中です。」と表示されていれば、稼動系サーバとして正常にサービスが開始されています。
データの更新を受け付けるようになったことを確認します (任意)。
=# INSERT INTO t VALUES (3); INSERT 0 1 =# SELECT * FROM t; c --- 1 3 (2 rows)
Copyright © 2003-2015 SRA OSS, Inc. Japan