切り替え発生後の縮退運転における運用操作について、説明します。
注意
プライマリサーバの異常によって切り替えが発生してからスタンバイサーバの組込みを行うまで、データベースは多重化構成ではありません。できるだけ早急に異常原因を取り除き、組込みを行ってください。
スタンバイサーバで参照系の業務を行っていた場合、プライマリサーバに異常が発生してサーバが切り替わると、新しく切り替わったプライマリサーバに負荷が集中します。したがって、旧スタンバイサーバで行っている参照系の業務を一時停止して、旧プライマリサーバを新スタンバイサーバとして組込んだあと、新スタンバイサーバに対して参照系の業務を再開することを推奨します。
異常が発生した旧プライマリサーバを新スタンバイサーバとして組込む前に、新しく切り替わったプライマリサーバのインスタンスを停止した場合には、旧プライマリサーバのインスタンスから起動するとスプリットブレインが発生します。そのため、新プライマリサーバのインスタンスを起動してから、スタンバイサーバの再構築を行ってください。
切り替えが発生して縮退運転が行われている場合は、以下の運用操作を行って、スタンバイサーバを復旧してもとの状態に戻します。
スタンバイサーバの組込み
プライマリサーバの切り戻し（必要な場合）
これらの運用操作の流れを以下の図に示します。
図8.1 運用操作の流れ
以下の手順でリカバリを実施してください。
異常が発生した旧プライマリサーバに対して、mc_ctlコマンドをstopモードで実行します。
例)
$ mc_ctl stop -M /mcdir/inst1
これにより、リカバリを実施する必要があるインスタンスも停止します。
注意
停止しない場合は、“運用ガイド”の“インスタンス停止失敗時の対処”を参照して、インスタンスを停止します。
そのあと、上記のコマンドにeオプションを指定してMirroring Controllerを強制停止してください。
プライマリサーバとスタンバイサーバのシステムログを参照して異常の原因を特定したあと、復旧します。
pg_basebackupコマンドを使用して、旧プライマリサーバのデータを新プライマリサーバと同期させてリカバリします。
以下の手順でリカバリを実施してください。
インスタンスの格納先ディレクトリ内の削除
OSのコマンドを使用して、旧プライマリサーバのインスタンスの格納先ディレクトリ配下の資源を削除してください。ディレクトリは削除しないでください。
テーブル空間の格納先ディレクトリの削除
テーブル空間の格納先ディレクトリがインスタンスのデータ格納先ディレクトリ配下以外に配置されている場合は、OSのコマンドを使用して、旧プライマリサーバのテーブル空間の格納先ディレクトリ配下の資源を削除します。ディレクトリは削除しないでください。
pg_basebackupコマンドによるインスタンスの同期
pg_basebackupコマンドの出力先のディレクトリに旧プライマリサーバのインスタンスのデータ格納先ディレクトリを指定して実行します。これにより、インスタンスを同期します。
例)
$ pg_basebackup -D /database/inst1 --xlog --progress --verbose -h 新プライマリサーバのIPアドレス -p 新プライマリサーバのポート番号
注意
新プライマリサーバのインスタンスのデータ格納先ディレクトリ配下において、pg_xlogディレクトリなどを負荷分散のためにシンボリックリンクを作成して運用している場合、pg_basebackupコマンドの実行ではシンボリックリンクを複製しません。
pg_basebackupコマンドの実行が正常終了したあと、旧プライマリサーバにおいてシンボリックリンクを作成しなおしてください。
旧プライマリサーバのrecovery.confファイルの編集
recovery.doneファイルが存在する場合は、recovery.confファイルにリネームしてprimary_conninfoパラメータを編集します。
recovery.doneファイルが存在しない場合は、バックアップしているrecovery.confファイルを複写するか、作成してください。
旧プライマリサーバのpostgresql.confファイルの編集
インスタンスの複製により、synchronous_standby_namesパラメータの内容がプライマリサーバでの指定内容になるため、スタンバイサーバでの指定内容へ修正します。コメントアウトされている場合は、アンコメントしてください。
参照
このリカバリ手順は、recovery.confファイルの作成方法以外は、スタンバイサーバをセットアップする手順と同じです。
“6.4 スタンバイサーバのインスタンスの作成・設定・登録”を参照して、リカバリを実施してください。
バックアップデータからMirroring Controller管理ディレクトリ配下のファイルをコピーして、リカバリを実施してください。
復旧した旧プライマリサーバをスタンバイサーバとして起動することをスタンバイサーバの組込みと呼びます。
旧プライマリサーバに対して、Mirroring Controllerとインスタンスを起動します。
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードでfオプションを指定して実行します。これにより、自動切り替え/切り離しの有効化を行います。
なお、fオプションを指定せずに起動した場合、自動切り替え/切り離しは有効になりません。有効にするには、Mirroring Controllerを起動したあとにmc_ctlコマンドをenable-failoverモードで実行するか、fオプションを指定してMirroring Controllerを再起動してください。
例)
$ mc_ctl start -M /mcdir/inst1 -f
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで実行します。
例)
$ mc_ctl start -M /mcdir/inst1
スタンバイサーバを組込んだあとにプライマリサーバとスタンバイサーバをもとの構成に戻したい場合は、プライマリサーバの切り戻しを行います。
以前のプライマリサーバで主な業務を行いたい場合に実施してください。
参照
recovery.confファイルの作成については、“6.4 スタンバイサーバのインスタンスの作成・設定・登録”を参照してください。
以下の手順で行います。
プライマリサーバの切り戻し
プライマリサーバとスタンバイサーバのどちらかでmc_ctlコマンドをswitchモードで実行します。
例)
$ mc_ctl switch -M /mcdir/inst1
mc_ctlコマンドをswitchモードで実行したあとは、以下の状態になります。
例)
$ mc_ctl status -M /mcdir/inst1 mirroring status ---------------- switched server_id host_role host host_status db_proc_status disk_status --------------------------------------------------------------------------------------------------- nd1 primary 192.0.2.100 normal abnormal(postmaster) normal nd2 none(inactivated primary) 192.0.2.110 normal abnormal(postmaster) normal
旧プライマリサーバの停止
旧プライマリサーバでmc_ctlコマンドをstopモードで実行して、Mirroring Controllerとインスタンスを停止します。
例)
$ mc_ctl stop -M /mcdir/inst1
旧プライマリサーバに新プライマリサーバのインスタンスの複製を作成
インスタンスの格納先ディレクトリ内の削除
OSのコマンドを使用して、旧プライマリサーバのインスタンスのデータ格納先ディレクトリ配下の資源を削除します。ディレクトリは削除しないでください。
テーブル空間の格納先ディレクトリの削除
テーブル空間の格納先がインスタンスのデータ格納先ディレクトリ配下以外に配置されている場合は、OSのコマンドを使用して、旧プライマリサーバのテーブル空間の格納先ディレクトリ配下の資源を削除します。ディレクトリは削除しないでください。
pg_basebackupコマンドによるインスタンスの同期
pg_basebackupコマンドの出力先のディレクトリに旧プライマリサーバのインスタンスのデータ格納先ディレクトリを指定して実行します。これにより、インスタンスを同期します。
例)
$ pg_basebackup -D /database/inst1 --xlog --progress --verbose -h 新プライマリサーバのIPアドレス -p 新プライマリサーバのポート番号
注意
新プライマリサーバのインスタンスのデータ格納先ディレクトリ配下において、pg_xlogディレクトリなどを負荷分散のためにシンボリックリンクを作成して運用している場合、pg_basebackupコマンドの実行ではシンボリックリンクを複製しません。
pg_basebackupコマンドの実行が正常終了したあと、旧プライマリサーバにおいてシンボリックリンクを作成しなおしてください。
旧プライマリサーバのrecovery.confファイルの編集
recovery.doneファイルが存在する場合は、recovery.confファイルにリネームしてprimary_conninfoパラメータを編集します。
recovery.doneファイルが存在しない場合は、recovery.confファイルを作成してください。
旧プライマリサーバのpostgresql.confファイルの編集
インスタンスの複製により、synchronous_standby_namesパラメータの内容がプライマリサーバでの指定内容になるため、スタンバイサーバでの指定内容へ修正します。コメントアウトされている場合は、アンコメントしてください。
参照
スタンバイサーバにプライマリサーバのインスタンスを複製する手順は、スタンバイサーバをセットアップする手順と同じです。
“6.4 スタンバイサーバのインスタンスの作成・設定・登録”を参照して、リカバリを実施してください。
スタンバイサーバの組込み
スタンバイサーバでMirroring Controllerとインスタンスを起動します。
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードでwオプションとfオプションを指定して実行します。これにより、自動切り替え/切り離しの有効化を行います。
なお、fオプションを指定せずに起動した場合、自動切り替え/切り離しは有効になりません。有効にするには、Mirroring Controllerを起動したあとにmc_ctlコマンドをenable-failoverモードで実行するか、fオプションを指定してMirroring Controllerを再起動してください。
例)
$ mc_ctl start -M /mcdir/inst1 -w -f
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードでwオプションを指定して実行します。
例)
$ mc_ctl start -M /mcdir/inst1 -w
