切り替え発生後の縮退運転における運用操作について、説明します。
注意
プライマリサーバの異常によって切り替えが発生してからスタンバイサーバの組込みを行うまで、データベースは多重化構成ではありません。できるだけ早急に異常原因を取り除き、組込みを行ってください。
スタンバイサーバで参照系の業務を行っていた場合、プライマリサーバに異常が発生してサーバが切り替わると、新しく切り替わったプライマリサーバに負荷が集中します。したがって、旧スタンバイサーバで行っている参照系の業務を一時停止して、旧プライマリサーバを新スタンバイサーバとして組込んだあと、新スタンバイサーバに対して参照系の業務を再開することを推奨します。
異常が発生した旧プライマリサーバを新スタンバイサーバとして組込む前に、新しく切り替わったプライマリサーバのインスタンスを停止した場合には、旧プライマリサーバのインスタンスから起動するとスプリットブレインが発生します。そのため、新プライマリサーバのインスタンスを起動してから、スタンバイサーバの再構築を行ってください。
切り替えが発生して縮退運転が行われている場合は、以下の運用操作を行って、スタンバイサーバを復旧してもとの状態に戻します。
これらの運用操作の流れを以下の図に示します。
図4.1 運用操作の流れ
以下の手順でリカバリを実施してください。
異常が発生した旧プライマリサーバに対して、mc_ctlコマンドをstopモードで実行します。
systemdを使用してMirroring Controllerの自動起動・停止の設定を実施している場合は、mc_ctlコマンドではなく、systemctlコマンドを使用してください。詳細は、“2.12 多重化したインスタンスとMirroring Controllerの自動起動・停止の設定”を参照してください。
例)
$ mc_ctl stop -M /mcdir/inst1
これにより、リカバリを実施する必要があるインスタンスも停止します。
注意
停止しない場合は、“運用ガイド”の“インスタンス停止失敗時の対処”を参照して、インスタンスを停止します。
そのあと、上記のコマンドに-eオプションを指定してMirroring Controllerを強制停止してください。
バックアップデータからMirroring Controller管理ディレクトリ配下のファイルをコピーして、リカバリを実施してください。
プライマリサーバとスタンバイサーバのシステムログを参照して異常の原因を特定したあと、復旧します。
スタンバイサーバの復旧方法として以下の2種類のコマンドが使用できます。復旧内容や状況に応じて選択してください。
pg_basebackupコマンド
プライマリサーバのインスタンスのすべての資源を複製します。
pg_rewindコマンド
新プライマリサーバの変更されたファイルのみを複製します。そのため、本コマンドを使用して新スタンバイサーバを組み込むことでリカバリ時間を短縮することができます。ただし、本コマンドを利用して旧プライマリサーバを新スタンバイサーバとして構築する場合、以下のいずれかの条件を満たす必要があります。
インスタンス作成時にチェックサムが有効化されている。または、
インスタンス起動時にpostgresql.confファイルのwal_log_hintsパラメータが有効化されている。
full_page_writesも有効でなければなりませんが、これはデフォルトで有効です。
参照
pg_basebackupコマンドの詳細については、“PostgreSQL Documentation”の“Reference”の“pg_basebackup”を参照してください。
pg_rewindコマンドの詳細については、“PostgreSQL Documentation”の“Reference”の“pg_rewind”を参照してください。
pg_rewindコマンドを実行して、旧プライマリサーバのデータを新プライマリサーバと同期してリカバリする例を以下に示します。
新プライマリサーバでの未適用更新トランザクションログの適用を待つ
新プライマリサーバで以下のSQLを実行し、結果がfalseになるまで待ちます。
# select pg_is_in_recovery();
例)
$ psql -h 新プライマリサーバのホスト名 -p 新プライマリサーバのポート番号 -d データベース名 -c "select pg_is_in_recovery();"
接続するデータベースは、どのデータベースでも問題ありません。
注意
新プライマリサーバの昇格直後にpg_rewindを実行する場合、手順1および手順2の処理が必要になります。新プライマリサーバで更新系のSQLを実行できるようになり、チェックポイント処理が昇格後に実行されている場合は、手順1および手順2の処理は不要です。
タイムラインIDの更新
チェックポイント処理を実行して、タイムラインIDを更新します。
$ psql -h 新プライマリサーバのホスト名 -p 新プライマリサーバのポート番号 -d データベース名 -c "checkpoint;"
接続するデータベースは、どのデータベースでも問題ありません。
旧プライマリサーバ(新スタンバイサーバ)に新プライマリサーバのインスタンスの複製を作成
pg_rewindコマンドを実行して、新スタンバイサーバのデータを新プライマリサーバと同期して作成します。
例)
$ pg_rewind -D /database/inst1 -R --source-server='user=ユーザー名 host=新プライマリサーバのホスト名 port=新プライマリサーバのポート番号 dbname=データベース名 application_name=新スタンバイサーバ名'
注意
pg_rewindコマンドには、-Rオプションを指定して実行し、standby.signalファイルを作成してください。standby.signalファイルを作成しない場合、Mirroring Controllerはスタンバイサーバとして起動できません。
プライマリサーバへの接続がパスワード認証を必要とする方式の場合、自動で認証が行われるようにしておく必要があります。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パラメータの設定に含めてください。
primary_conninfoパラメータは、postgresql.confファイルには設定せず、pg_rewindコマンドを使用してpostgresql.auto.confファイルのみに設定してください。
旧プライマリサーバ(新スタンバイサーバ)のpostgresql.confファイルにパラメータを設定
スタンバイサーバ側に必要なパラメータをpostgresql.confファイルに設定します。
postgresql.confファイルに設定するパラメータは、“表2.5 設定するパラメータ”を参照して設定してください。
参照
standby.signalファイルの詳細については、“PostgreSQL Documentation”の“Hot Standby”を参照してください。
primary_conninfoの詳細については、“PostgreSQL Documentation”の“Setting Up a Standby Server”を参照してください。
注意
新プライマリサーバは昇格によって新たなタイムラインに分岐されているため、旧プライマリサーバ(新スタンバイサーバ)が新プライマリサーバに追随するためには、recovery_target_timelineパラメータに'latest'を指定する必要があります。
復旧した旧プライマリサーバをスタンバイサーバとして起動することをスタンバイサーバの組込みと呼びます。
旧プライマリサーバに対して、Mirroring Controllerとインスタンスを起動します。
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで実行します。
例)
$ mc_ctl start -M /mcdir/inst1
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで-Fオプションを指定して実行します。
例)
$ mc_ctl start -M /mcdir/inst1 -F
ポイント
自動切り替え/切り離しはMirroring Controllerが起動したあとに、mc_ctlコマンドのenable-failoverモード、または、disable-failoverモードを使用することにより自動切り替え/切り離しを有効、または無効にすることが可能です。
スタンバイサーバを組込んだあとにプライマリサーバとスタンバイサーバをもとの構成に戻したい場合は、プライマリサーバの切り戻しを行います。
以前のプライマリサーバで主な業務を行いたい場合に実施してください。
以下の手順で行います。
プライマリサーバの切り戻し
プライマリサーバとスタンバイサーバのどちらかで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 --------------------------------------------------------------------------------------------------- server1 primary 192.0.2.100 normal abnormal(postmaster) normal server2 none(inactivated primary) 192.0.2.110 normal abnormal(postmaster) normal
旧プライマリサーバの停止
旧プライマリサーバでmc_ctlコマンドをstopモードで実行して、Mirroring Controllerとインスタンスを停止します。
systemdを使用してMirroring Controllerの自動起動・停止の設定を実施している場合は、mc_ctlコマンドではなく、systemctlコマンドを使用してください。詳細は、“2.12 多重化したインスタンスとMirroring Controllerの自動起動・停止の設定”を参照してください。
例)
$ mc_ctl stop -M /mcdir/inst1
旧プライマリサーバ(新スタンバイサーバ)に新プライマリサーバのインスタンスの複製を作成
pg_basebackupコマンドを実行して、新スタンバイサーバのデータを新プライマリサーバと同期して作成します。
例)
$ pg_basebackup -D /database/inst1 -X fetch --waldir=/transaction/inst1 --progress --verbose -R --dbname='application_name=スタンバイサーバ名' -h プライマリサーバのホスト名 -p プライマリサーバのポート番号
参照
新スタンバイサーバに新プライマリサーバのインスタンスを複製する手順は、新スタンバイサーバをセットアップする手順と同じです。
“2.5.2 スタンバイサーバのインスタンスの作成・設定・登録”を参照して、リカバリを実施してください。
スタンバイサーバの組込み
スタンバイサーバでMirroring Controllerとインスタンスを起動します。
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで実行します。
例)
$ mc_ctl start -M /mcdir/inst1
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで-Fオプションを指定して実行します。
例)
$ mc_ctl start -M /mcdir/inst1 -F
ポイント
自動切り替え/切り離しはMirroring Controllerが起動したあとに、mc_ctlコマンドのenable-failoverモード、または、disable-failoverモードを使用することにより自動切り替え/切り離しを有効、または無効にすることが可能です。
