★PostgreSQLカンファレンス2024 12月6日開催/チケット販売中★
他のバージョンの文書 16 | 15 | 14 | 13 | 12 | 11 | 10 | 9.6 | 9.5 | 9.4 | 9.3 | 9.2 | 9.1 | 9.0 | 8.4 | 8.3 | 8.2 | 8.1 | 8.0 | 7.4 | 7.3 | 7.2

25.2. ログシッピングスタンバイサーバ

継続的なアーカイブ処理を使用して、プライマリサーバが失敗した場合に操作を引き継ぐ準備がなされた、1つ以上のスタンバイサーバを持つ高可用性(HA)クラスタ構成を作成することができます。 この機能はウォームスタンバイまたはログシッピングとして広く知られています。

プライマリサーバとスタンバイサーバは、この機能を提供するために共同して稼動しますが、サーバとサーバはゆるく結合しています。 プライマリサーバは継続的アーカイブモードで動作し、各スタンバイサーバはプライマリからWALファイルを読み取る、継続的リカバリモードで動作します。 この機能を可能にするために、データベースのテーブル変更は不要です。 したがって、他のレプリケーションの解法に比べて、管理的なオーバーヘッドが減少します。 この構成はプライマリサーバの性能への影響も相対的に減少させます。

あるデータベースサーバから他へ直接WALレコードを移動することは通常、ログシッピングと説明されます。 PostgreSQLはファイルベースのログシッピングを実装します。 つまりWALレコードはある時点で1つのファイル(WALセグメント)として送信されることを意味します。 WALファイル(16MB)は隣り合うシステム、同じサイトの別システム、地球の裏側のシステムなど距離に関わらず、簡単かつ安価に送付することができます。 この技法に必要な帯域幅はプライマリサーバのトランザクションの頻度に応じて変動します。 また、レコードベースのログシッピングをストリーミングレプリケーション( 項25.2.5参照)を用いて使用することができます。

ログシッピングが非同期であることに注意しなければなりません。 つまり、WALレコードはトランザクションがコミットした後に転送されます。 結果として、プライマリサーバが災害などの致命的な失敗をうけた場合、送信されていないトランザクションが失われますので、データを損失する空白期間があります。 ファイルベースのログシッピングにおけるデータ損失の空白期間量をarchive_timeoutパラメータを用いて制限することができます。 これは数秒程度まで小さく設定することができます。 しかし、低く設定するとファイル転送に必要な帯域幅が増大します。 1分以下または1分程度で空白期間を抑えなければならないのであれば、ストリーミングレプリケーション(項25.2.5参照)の使用を検討してください。

リカバリ処理の性能は十分よく、一度実施されれば、スタンバイサーバが完全な状態から逸脱するのは一時的にしかすぎません。 結果としてこれは、高可用性を提供するウォームスタンバイ構成と呼ばれます。 保管されたベースバックアップからサーバをリストアし、ロールフォワードを行うことはおそらく長時間かかりますので、これは高可用性のための解法とはいえず、災害からのリカバリのための解法です。 スタンバイサーバは読み取り専用の問い合わせに使用することもできます。 この場合ホットスタンバイサーバと呼ばれます。 詳細については項25.5を参照してください。

25.2.1. 計画

プライマリサーバとスタンバイサーバを、少なくともデータベースサーバという見地でできる限り同じになるように作成することを通常勧めます。 具体的には、テーブル空間に関連するパス名はそのまま渡されますので、テーブル空間機能を使用する場合には、プライマリとスタンバイサーバの両方でテーブル空間用のマウントパスを同じにしておかなければなりません。 CREATE TABLESPACEをプライマリで実行する場合、そのコマンドを実行する前に必要な新しいマウントポイントをプライマリとすべてのスタンバイサーバで作成しなければならないことに注意してください。 ハードウェアをまったく同じにする必要はありませんが、経験上アプリケーションとシステムの運用期間に渡って2つの同じシステムを管理する方が、異なる2つのシステムを管理するよりも簡単です。 いずれにしてもハードウェアアーキテクチャは必ず同じでなければなりません。 例えば32ビットシステムから64ビットシステムへのシッピングは動作しません。

マイナーリリースの更新ではディスク書式を変更しないというのがPostgreSQLグローバル開発グループの方針ですので、プライマリサーバとスタンバイサーバとの間でマイナーリリースレベルの違いがあってもうまく動作するはずです。 しかし、この場合、公的なサポートは提供されません。 できる限りプライマリサーバとスタンバイサーバとで同じリリースレベルを使用してください。 新しいマイナーリリースに更新する場合、もっとも安全な方針はスタンバイサーバを先に更新することです。 新しいマイナーリリースは以前のマイナーリリースのWALファイルを読み込むことはできますが、逆はできないかもしれません。

25.2.2. スタンバイサーバの動作

スタンバイモードでは、サーバは継続的にマスタサーバから受け取ったWALを適用します。 スタンバイサーバはWALアーカイブ(restore_command参照)から、または直接TCP接続(ストリーミングレプリケーション)を介してマスタサーバから、WALを読み取ることができます。 またスタンバイサーバはスタンバイクラスタのpg_xlogディレクトリにあるすべてのWALをリストアしようと試みます。 これはよくサーバの再起動後、スタンバイが再起動前にマスタから流れ込んだWALを再生する時に発生します。 しかしまたファイルを再生する任意の時点で、手作業でpg_xlogにコピーすることもできます。

起動時、スタンバイサーバはrestore_commandを呼び出して、アーカイブ場所にある利用可能なすべてのWALをリストアすることから始めます。 そこで利用可能なWALの終端に達し、restore_commandが失敗すると、pg_xlogディレクトリにある利用可能な任意のWALのリストアを試みます。 ストリーミングレプリケーションが設定されている場合、これに失敗すると、スタンバイはプライマリサーバへの接続を試み、アーカイブまたはpg_xlog内に存在した最終の有効レコードからWALのストリーミングを開始します。 ストリーミングレプリケーションが設定されていない場合、これに失敗する場合、または、接続が後で切断される場合、スタンバイは最初に戻り、アーカイブからのファイルのリストアを繰り返し行います。 このアーカイブ、pg_xlog、ストリーミングレプリケーションからという再試行の繰り返しはサーバが停止する、あるいはトリガファイルによるフェールオーバが発行されるまで続きます。

トリガファイル(trigger_file)が存在すると、スタンバイモードは終了し、サーバは通常の動作に切り替わります。 フェールオーバの前に、アーカイブまたはpg_xlog内の即座に利用可能なWALをすべてリストアします。 しかし、マスタへの接続を行おうとはしません。

25.2.3. スタンバイサーバのためのマスタの準備

項24.3で説明したように、スタンバイからアクセス可能なアーカイブディレクトリに対してプライマリで継続的なアーカイブを設定してください。 このアーカイブ場所はマスタが停止した時であってもスタンバイからアクセス可能でなければなりません。 つまり、マスタサーバ上ではなく、スタンバイサーバ自身上に存在するか、または他の高信頼性サーバ上に存在しなければなりません。

ストリーミングレプリケーションを使用したい場合、スタンバイサーバ(複数可)からのレプリケーション接続を受け付けるようにプライマリサーバで認証を設定してください。 つまり、そのデータベースフィールドとしてreplicationを持つ適切な項目をpg_hba.conf内に設定します。 また、プライマリサーバの設定ファイルにおいてmax_wal_sendersが十分大きな値に設定されていることを確認してください。

項24.3.2に記述したように、スタンバイサーバの再起動のために、ベースバックアップを取得してください。

25.2.4. スタンバイサーバの設定

スタンバイサーバを設定するためには、プライマリサーバから取得したベースバックアップをリストアしてください(項24.3.3参照)。 スタンバイのクラスタデータディレクトリ内にrecovery.confリカバリコマンドファイルを作成し、standby_modeを有効にしてください。 WALアーカイブからファイルをコピーする簡単なコマンドをrestore_commandに設定してください。

注意: ここで説明した組込みのスタンバイモードといっしょにpg_standbyや類似ツールを使用しないでください。 restore_commandはファイルが存在しない場合に即座に終了しなければなりません。 サーバが必要に応じてそのコマンドを再度実行します。 pg_standbyのようなツールを使用するためには項25.4を参照してください。

ストリーミングレプリケーションを使用したい場合には、ホスト名(またはIPアドレス)とプライマリサーバとの接続に必要な追加情報を含む、libpq接続文字列でprimary_conninfoを記述してください。 プライマリで認証用のパスワードが必要な場合はprimary_conninfoにそのパスワードも指定する必要があります。

スタンバイサーバを高可用性を目的に設定しているのであれば、スタンバイサーバはフェールオーバの後プライマリサーバとして動作しますので、プライマリサーバと同様にWALアーカイブ処理、接続、認証を設定してください。 またフェールオーバを行うことができるようにtrigger_fileを設定する必要があります。 そこにフェールオーバする予定がなく報告を目的としたスタンバイサーバを設定する場合、trigger_fileは不要です。

WALアーカイブを使用している場合、archive_cleanup_commandパラメータを使用してスタンバイサーバで不要となったファイルを削除することで、その容量を最小化することができます。 特にpg_archivecleanupユーティリティは、典型的な単一スタンバイ構成(項F.22参照)におけるarchive_cleanup_commandと共に使用されるように設計されています。 しかし、バックアップを目的にアーカイブを使用している場合には、スタンバイから必要とされなくなったファイルであっても、最新のベースバックアップの時点からリカバリするために必要なファイルを保持しなければならないことに注意してください。

recovery.confの簡単な例を以下に示します。

standby_mode = 'on'
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
restore_command = 'cp /path/to/archive/%f %p'
trigger_file = '/path/to/trigger_file'
archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r'

スタンバイサーバの台数に制限はありませんが、ストリーミングレプリケーションを使用するなら、プライマリサーバに同時に接続できるようにmax_wal_sendersを十分な数に設定してください。

25.2.5. ストリーミングレプリケーション

ストリーミングレプリケーションによりスタンバイサーバはファイルベースのログシッピングよりもより最近の状態を維持できるようになります。 スタンバイは、WALレコードが生成された時にWALファイルがいっぱいになるまで待機せずにWALレコードをスタンバイに流し出すプライマリと接続します。

ストリーミングレプリケーションは非同期です。 このため、プライマリでトランザクションがコミットされてから、その変更がスタンバイ側で参照可能になるまでの間にわずかな遅延がまだあります。 しかし、この遅延はファイルベースのログシッピングよりも非常に小さなもので、ロードを維持できる程度の能力があるスタンバイであれば通常は1秒以下です。 ストリーミングレプリケーションでは、データ損失期間を減らすためのarchive_timeoutを必要としません。

ファイルベースの継続的アーカイブのないストリーミングレプリケーションを使用している場合、マスタにおいてwal_keep_segmentsの値を、スタンバイが古いWALセグメントに追随する必要がある時にそれらががあまりに早く回収されないことが確実になるように十分大きく設定しなければなりません。 スタンバイ側が大きく遅れてしまった場合、新しいベースバックアップから再初期化する必要があります。 スタンバイからアクセスできるようにWALアーカイブを設定する場合は、スタンバイは常に追随するためにアーカイブを使用することができますので、wal_keep_segmentsは必要ありません。

ストリーミングレプリケーションを使用するためには、項25.2の説明のようにファイルベースのログシッピングを行うスタンバイサーバを設定してください。 ファイルベースのログシッピングを行うスタンバイをストリーミングレプリケーションを行うスタンバイに切り替える手順は、recovery.conf内のprimary_conninfo設定をプライマリサーバを指し示すように設定することです。 スタンバイサーバがプライマリサーバ上のreplication疑似データベースに接続できる(項25.2.5.1参照)ように、プライマリでlisten_addressesと認証オプション(pg_hba.conf参照)を設定してください。

キープアライブソケットオプションをサポートするシステムでは、tcp_keepalives_idletcp_keepalives_intervalおよびtcp_keepalives_countを設定することで、プライマリの接続切断の即時検知に有用です。

スタンバイサーバからの同時接続数の最大値を設定してください(詳細はmax_wal_sendersを参照)。

スタンバイが起動し、primary_conninfoが正しく設定されると、スタンバイはアーカイブ内で利用可能なWALファイルをすべて再生した後にプライマリと接続します。 接続の確立に成功すると、スタンバイで WAL 受信プロセスが存在し、プライマリで対応する WAL 送信プロセスが存在します。

25.2.5.1. 認証

信頼できるユーザのみがWALストリームを読み取ることができるように、レプリケーション用のアクセス権限を設定することは非常に重要です。 WALから機密情報を取り出すことは簡単だからです。 スタンバイサーバはプライマリに対してスーパーユーザアカウントとして認証されなければなりません。 このため、SUPERUSERおよびLOGIN権限を持つロールをプライマリ上で作成しなければなりません。

レプリケーション用のクライアント認証はpg_hba.conf内でそのdatabaseフィールドにreplicationを指定したレコードで制御されます。 例えば、スタンバイがIPアドレス192.168.1.100のホストで稼動し、レプリケーション用のスーパーユーザの名前がfooである場合、管理者はプライマリ上のpg_hba.confに以下の行を追加することができます。

# 利用者 foo のホスト 192.168.1.100 からプライマリサーバへのレプリケーションスタンバイとしての接続を
# 利用者のパスワードが正しく入力されたならば許可する
#
# TYPE  DATABASE        USER            CIDR-ADDRESS            METHOD
host    replication     foo             192.168.1.100/32        md5

プライマリサーバのホスト名とポート番号、接続する利用者名およびパスワードは、recovery.confファイルで指定します。 パスワードはスタンバイサーバの~/.pgpassファイルでも設定できます(databaseフィールドのreplicationを指定します)。 例えば、プライマリサーバが稼動するホストの IP アドレスが192.168.1.50でポート番号が5432であり、レプリケーションのスーパユーザ名がfooであり、パスワードがfoopassである場合、管理者はスタンバイサーバのrecovery.confファイルに次行を追加できます。

# プライマリサーバが 192.168.1.50 のホストの 5432ポートで稼動し
# 利用者名が foo でパスワードが foopass とする
primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'

25.2.5.2. 監視

ストリーミングレプリケーションの状態の重要な検知法は、プライマリサーバで生成されたがスタンバイサーバでは未利用の WAL レコードの量です。 プライマリサーバの現在の WAL 書き込み位置とスタンバイサーバの受理した WAL の最終位置を比較すれば、この遅延を計算できます。 これらの位置は、プライマリサーバではpg_current_xlog_locationをスタンバイサーバではpg_last_xlog_receive_locationを使用すれば検索できます(詳細は表9-56および表9-57を参照)。 スタンバイサーバの最終位置は、psコマンドを使用して WAL 受理プロセスの状態としても表示できます(詳細は項27.1を参照)。