ストリーミングレプリケーション ～ 運用のための機能 ～
PostgreSQLインサイド

ストリーミングレプリケーションの仕組みと構成のポイントについては、「ストリーミングレプリケーション ～ 仕組み、構成のポイント ～」で説明しました。
ここでは、ストリーミングレプリケーションのフェイルオーバとリカバリーのポイントについて説明します。なお、本資料では、PostgreSQL 11で設定可能なパラメーターおよび機能を使用して説明しています。

ポイント

PostgreSQL 12では、設定ファイルのrecovery.confに指定するパラメーターが、postgresql.confに統合されました。PostgreSQL 12を使用する場合、recovery.confが存在するとPostgreSQLサーバが起動しないなどの仕様変更があります。本資料のrecovery.confに関する記事は、別途仕様を確認してください。仕様の詳細については、“PostgreSQL Documentation”の“Release Notes”の“Migration to Version 12”を参照してください。

1. フェイルオーバ

プライマリサーバに障害が発生した場合、スタンバイサーバに切り替えることで、業務を継続することができます。
PostgreSQLには異常を検知する機能や自動的な切り替え機能は存在しないため、異常を検知する仕組みを組み込み、さらに、スタンバイサーバを昇格（pg_ctl promote）させるスクリプトを組み込んでおく必要があります。または、異常検知や自動切り替え機能を備えた、Pgpool-IIなどのクラスタソフトウェアを利用してください。

2. リカバリー

サーバダウン後の対処は、プライマリサーバがダウンした場合と、スタンバイサーバがダウンした場合で異なります。ここでは、同期レプリケーション構成の場合を例に、それぞれの対処方法について説明します。

2.1 プライマリサーバがダウンした場合

プライマリサーバがダウンした後、ダウンしたサーバ（旧プライマリサーバ）をスタンバイサーバとして再構築する必要があります。旧プライマリサーバを復旧する方法として様々ありますが、以下の代表的な2つの方法を紹介します。

2.1.1 ベースバックアップを利用する方法（pg_basebackupコマンド）

新プライマリサーバから最新のデータベースクラスタをコピー（pg_basebackupコマンド）し、スタンバイサーバとして必要な設定を行った上で起動することで、ダウンした旧プライマリサーバを、新しいスタンバイサーバとして構築することができます。データベースが大きい場合は、再構築までに時間がかかります。

リカバリーの概要

リカバリーの手順

1. 障害原因の特定と対処を行い、 ダウンした旧プライマリサーバを復旧します。
2. 旧プライマリサーバで、旧プライマリサーバのデータベースクラスタを削除します。
3. 旧プライマリサーバで、pg_basebackupコマンド（-Rオプション）を実行し、新プライマリサーバから物理バックアップを取得します。
4. 旧プライマリサーバで、recovery.confを修正します。

   • standby_mode=onを設定
   • primary_conninfoにapplication_nameを追加
5. 旧プライマリサーバで、postgresql.confを修正します。

   • synchronous_standby_namesの無効化
6. 旧プライマリサーバを起動し、新スタンバイサーバにします。
7. 新プライマリサーバで、postgresql.confを修正します。

   • synchronous_standby_namesに同期レプリケーションを行うスタンバイサーバ名を設定し、リロードします。

2.1.2 ダウンしたクラスタファイルを利用する方法（pg_rewindコマンド）

旧プライマリサーバのデータベースにハードウェアを起因とする障害が発生しておらず、データベースを再起動することが可能な場合は、ダウンしたクラスタファイルを利用して復旧することができます。
旧プライマリサーバと新プライマリサーバの差分を同期（pg_rewindコマンド）させ、スタンバイサーバとして必要な設定を行った上で起動することで、ダウンした旧プライマリサーバを新しいスタンバイサーバとして構築することができます。pg_basebackupコマンドと比べ、pg_rewindコマンドは比較的短時間で再構築することができます。ただし、pg_rewindコマンドを使用するには、以下の条件があるので注意が必要です。

• 旧プライマリサーバが正常停止している
• postgresql.confのwal_log_hintsパラメーターが有効またはinitdbでデータベースクラスタを初期化する時にデータチェックサムが有効

リカバリーの概要

リカバリーの手順

1. 障害原因の特定と対処を行い、 ダウンした旧プライマリサーバを復旧します。
2. 旧プライマリサーバは正常停止している必要があるため、停止した旧プライマリサーバを一旦起動したあと、正常停止させます。
3. 旧プライマリサーバで、pg_rewindコマンドを実行します。
4. 旧プライマリサーバで、recovery.confを作成します。

   • standby_mode=onを設定
   • recovery_target_timeline=latestを指定
   • primary_conninfoにapplication_nameを設定
5. 旧プライマリサーバで、postgresql.confを修正します。

   • synchronous_standby_namesの無効化
6. 旧プライマリサーバを起動し、新スタンバイサーバにします。
7. 新プライマリサーバで、postgresql.confを修正します。

   • synchronous_standby_namesに同期レプリケーションを行うスタンバイサーバ名を設定し、リロードします。
8. 新スタンバイサーバと新プライマリサーバのタイムラインIDが揃っていることを確認します。タイムラインIDは、pg_controldataコマンドで取得できます。

2.2 スタンバイサーバがダウンした場合

スタンバイサーバがダウンした場合の対処は、スタンバイサーバが同期レプリケーションなのか、非同期レプリケーションなのかで異なります。それぞれの対処方法について説明します。

2.2.1 同期レプリケーションの場合

同期レプリケーションとして動作中のスタンバイサーバがダウンすると、プライマリサーバは、スタンバイサーバからの応答待ちの状態となり、クライアントにCOMMITの応答を返すことができなくなります。そのため、異常があった同期レプリケーションのスタンバイサーバを切り離す（非同期レプリケーションにする）必要があります。プライマリサーバのpostgresql.confのsynchronous_standby_namesパラメーターから異常のあったスタンバイサーバ名を削除し、ファイルの再読み込み（pg_ctl reload）を行ってください。すべてのスタンバイサーバが停止した場合は、synchronous_standby_namesパラメーターを空にしてから再読み込みを行ってください。
スタンバイサーバの復旧は、「プライマリサーバがダウンした場合」と同様の手順です。

2.2.2 非同期レプリケーションの場合

非同期レプリケーションであるため、スタンバイサーバがダウンした際に、postgresql.confの編集やファイルの再読み込みを行う必要はありません。
スタンバイサーバの復旧は、「プライマリサーバがダウンした場合」と同様の手順です。

PostgreSQLのストリーミングレプリケーションの運用について解説しました。ストリーミングレプリケーション機能を活用し、データベースの高可用化にお役立てください。
FUJITSU Software Enterprise Postgresでは、異常検知や自動フェイルオーバなど、実際の業務に必要な機能を備えた「データベース多重化機能」があります。
ぜひ、FUJITSU Software Enterprise Postgresのご利用もご検討ください。

2020年2月14日更新

こちらもおすすめ

• ストリーミングレプリケーション ～ 仕組み、構成のポイント ～
• Pgpool-IIで高可用なシステム構成を考える
• 技術を知る：PostgreSQLの災害対策 ～ 地震や豪雨からデータを守る災害対策 ～
• 技術者に聞く：PostgreSQLの災害対策 ～ 災害への備えは万全に! ログの順序性保証で確実なレプリケーション ～
• 富士通の技術者に聞く!PostgreSQL最新技術 WALが損失するという課題の解決

本コンテンツに関するお問い合わせ