C.5.1 プライマリサーバの異常時

プライマリサーバが異常となり、かつプライマリサーバとして復旧させる場合については、“第4章フェイルオーバ運用の異常時の対処”を参照してください。

ただし、プライマリサーバのインスタンスをバックアップデータから復旧するなど、スタンバイサーバの再構築も必要となった場合には、“C.5.2 スタンバイサーバの異常時”を参照して、スタンバイサーバの再構築を行ってください。

スタンバイサーバが新プライマリサーバに昇格したあとで、異常となった元プライマリサーバをスタンバイサーバとして組み込み復旧する場合も、“第4章フェイルオーバ運用の異常時の対処”を参照し、リカバリの準備を行います。ただし、“4.3 データベースクラスタの起動”から“4.6 保守停止の解除”までの手順の代わりに、以下の手順を実行してください。

スタンバイサーバの復旧方法として以下の2種類のコマンドが使用できます。復旧内容や状況に応じて選択してください。

pg_basebackupコマンド
プライマリサーバのインスタンスのすべての資源を複製します。再構築の手順は“C.5.2 スタンバイサーバの異常時”を参照してください。
pg_rewindによるリカバリ
新プライマリサーバで変更されたファイルのみを複製します。そのため、本コマンドを使用して新スタンバイサーバを組み込むことでリカバリ時間を短縮することがきます。ただし、本コマンドを利用して旧プライマリサーバを新スタンバイサーバとして構築する場合、以下のいずれかの条件を満たす必要があります。
1. インスタンス作成時にチェックサムが有効化されている。かつ、旧プライマリサーバが正常に停止されている。または、
2. 旧プライマリサーバが正常に停止されている。かつ、インスタンス起動時にpostgresql.confファイルのwal_log_hintsパラメータが有効化されている。
full_page_writesも有効でなければなりませんが、これはデフォルトで有効です。
pg_rewindコマンドを実行して、旧プライマリサーバのデータを新プライマリサーバと同期してリカバリする例を以下に示します。
1. 旧プライマリサーバのインスタンスの起動
  pg_ctlコマンドを使用して、旧プライマリサーバのインスタンスを起動します。
```
例)
```
```
$ pg_ctl start -D データ格納先ディレクトリ
```
2. 旧プライマリサーバのインスタンスの停止
  pg_ctlコマンドを使用して、旧プライマリサーバのインスタンスを停止します。
```
例)
```
```
$ pg_ctl stop -D データ格納先ディレクトリ
```
3. 新プライマリサーバでの未適用更新トランザクションログの適用を待つ
  新プライマリサーバで以下のSQLを実行し、結果がfalseになるまで待ちます。
```
select pg_is_in_recovery();
```
```
例)
```
```
$ psql -h 新プライマリサーバのホスト名 -p 新プライマリサーバのポート番号 -d データベース名 -c "select pg_is_in_recovery();"
```
  接続するデータベースは、どのデータベースでも問題ありません。
  注意
  新プライマリサーバの昇格直後にpg_rewindを実行する場合、手順3および手順4の処理が必要になります。新プライマリサーバで更新系のSQLを実行できるようになり、チェックポイント処理が昇格後に実行されている場合は、手順3および手順4の処理は不要です。
4. タイムラインIDの更新
  チェックポイント処理を実行して、タイムラインIDを更新します。
```
$ psql -h 新プライマリサーバのホスト名 -p 新プライマリサーバのポート番号 -d データベース名 -c "checkpoint;"
```
  接続するデータベースは、どのデータベースでも問題ありません。
5. 旧プライマリサーバ(新スタンバイサーバ)に新プライマリサーバのインスタンスの複製を作成
  pg_rewindコマンドを実行して、新スタンバイサーバのデータを新プライマリサーバと同期して作成します。
```
例)
```
```
$ pg_rewind -D 旧プライマリサーバのデータ格納先ディレクトリ -R --source-server='user=ユーザー名 host=新プライマリサーバのホスト名 port=新プライマリサーバのポート番号 dbname=データベース名'
```
  注意
  - pg_rewindコマンドには、-Rオプションを指定して実行し、standby.signalファイルを作成してください。standby.signalファイルを作成しない場合、スタンバイサーバとして起動できません。
  - プライマリサーバへの接続がパスワード認証を必要とする方式の場合、自動で認証が行われるようにしておく必要があります。pg_rewindコマンドの-Rオプションを指定し、--source-serverオプションにpasswordパラメータを指定すると、pg_rewindコマンドによりpostgresql.auto.confファイルのprimary_conninfoパラメータにパスワードが設定されて自動的に接続できるようになります。
  - postgresql.auto.confファイルのprimary_conninfoパラメータにパスワードを設定しない場合は、インスタンス管理者ユーザーのホームディレクトリに.pgpassファイルを作成してreplicationデータベースに対するパスワードを設定してください。
  - host、portおよびapplication_name以外に設定が必要な接続文字列がある場合は、primary_conninfoパラメータの設定に含めてください。
  参照
  - standby.signalファイルの詳細については、“PostgreSQL Documentation”の“Hot Standby”を参照してください。
  - primary_conninfoの詳細については、“PostgreSQL Documentation”の“Setting Up a Standby Server”を参照してください。
6. 旧プライマリサーバ(新スタンバイサーバ)のpostgresql.confファイルにパラメータを設定
  新スタンバイサーバに必要なパラメータをpostgresql.confファイルに設定します。
  postgresql.confファイルに設定するパラメータは、“データベースクラスタの作成”を参照して設定してください。
  注意
  新プライマリサーバは昇格によって新たなタイムラインに分岐されているため、旧プライマリサーバ(新スタンバイサーバ)が新プライマリサーバに追随するためには、recovery_target_timelineパラメータに'latest'を指定する必要があります。
7. リソースの開放
  データ格納先用のディレクトリを配置したファイルシステムなど、マウントしたファイルシステムをアンマウントしてください。その後、GDSボリュームを停止してください。
8. 保守停止の解除
  “3.5 保守作業”を参照して、保守停止の解除を実施してください。
9. 動作確認
  “動作確認”を参照し、動作確認を実施してください。

参照

pg_basebackupコマンドの詳細については、“PostgreSQL Documentation”の“Reference”の“pg_basebackup”を参照してください。
pg_rewindコマンドの詳細については、“PostgreSQL Documentation”の“Reference”の“pg_rewind”を参照してください。