切り替え発生後の縮退運転における運用操作について、説明します。
注意
プライマリサーバの異常によって切り替えが発生してからスタンバイサーバの組込みを行うまで、データベースは多重化構成ではありません。できるだけ早急に異常原因を取り除き、組込みを行ってください。
スタンバイサーバで参照系の業務を行っていた場合、プライマリサーバに異常が発生してサーバが切り替わると、新しく切り替わったプライマリサーバに負荷が集中します。したがって、旧スタンバイサーバで行っている参照系の業務を一時停止して、旧プライマリサーバを新スタンバイサーバとして組込んだあと、新スタンバイサーバに対して参照系の業務を再開することを推奨します。
異常が発生した旧プライマリサーバを新スタンバイサーバとして組込む前に、新しく切り替わったプライマリサーバのインスタンスを停止した場合には、旧プライマリサーバのインスタンスから起動するとスプリットブレインが発生します。そのため、新プライマリサーバのインスタンスを起動してから、スタンバイサーバの再構築を行ってください。
切り替えが発生して縮退運転が行われている場合は、以下の運用操作を行って、スタンバイサーバを復旧してもとの状態に戻します。
これらの運用操作の流れを以下の図に示します。
図5.1 運用操作の流れ
以下の手順でリカバリを実施してください。
異常が発生した旧プライマリサーバに対して、mc_ctlコマンドをstopモードで実行します。
例)
$ 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_hba.confファイルの設定を変更するなどしてクライアントの接続を許可しないようにしてください。
参照
pg_rewindコマンドの詳細については、“PostgreSQL文書”の“リファレンス”の“pg_rewind”を参照してください。
pg_rewindコマンドを実行して、旧プライマリサーバのデータを新プライマリサーバと同期してリカバリする例を以下に示します。
旧プライマリサーバのインスタンスの起動
pg_ctlコマンドを使用して、旧プライマリサーバのインスタンスを起動します。
例)
$ pg_ctl start -w -D /database/inst1
旧プライマリサーバのインスタンスの停止
pg_ctlコマンドを使用して、旧プライマリサーバのインスタンスを停止します。
例)
$ pg_ctl stop -D /database/inst1
旧プライマリサーバ(新スタンバイサーバ)に新プライマリサーバのインスタンスの複製を作成
pg_rewindコマンドを実行して、新スタンバイサーバのデータを新プライマリサーバと同期して作成します。
例)
$ pg_rewind -D /database/inst1 --source-server='user=ユーザー名 host=新プライマリサーバのホスト名 port=新プライマリサーバのポート番号'
復旧した旧プライマリサーバをスタンバイサーバとして起動することをスタンバイサーバの組込みと呼びます。
旧プライマリサーバに対して、Mirroring Controllerとインスタンスを起動します。
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで-fオプションを指定して実行します。これにより、自動切り替え/切り離しの有効化を行います。
なお、-fオプションを指定せずに起動した場合、自動切り替え/切り離しは有効になりません。有効にするには、Mirroring Controllerを起動したあとにmc_ctlコマンドをenable-failoverモードで実行するか、-fオプションを指定してMirroring Controllerを再起動してください。
例)
$ mc_ctl start -M /mcdir/inst1 -w -f
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで実行します。
例)
$ mc_ctl start -M /mcdir/inst1 -w
スタンバイサーバを組込んだあとにプライマリサーバとスタンバイサーバをもとの構成に戻したい場合は、プライマリサーバの切り戻しを行います。
以前のプライマリサーバで主な業務を行いたい場合に実施してください。
以下の手順で行います。
プライマリサーバの切り戻し
プライマリサーバとスタンバイサーバのどちらかで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
旧プライマリサーバ(新スタンバイサーバ)に新プライマリサーバのインスタンスの複製を作成
pg_basebackupコマンドを実行して、新スタンバイサーバのデータを新プライマリサーバと同期して作成します。
例)
$ pg_basebackup -D /database/inst1 --xlog --progress --verbose -R --dbname='application_name=スタンバイサーバ名' -h プライマリサーバのホスト名 -p プライマリサーバのポート番号
参照
新スタンバイサーバに新プライマリサーバのインスタンスを複製する手順は、新スタンバイサーバをセットアップする手順と同じです。
“3.4.2 スタンバイサーバのインスタンスの作成・設定・登録”を参照して、リカバリを実施してください。
スタンバイサーバの組込み
スタンバイサーバで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
