切り替え発生後の縮退運転における運用操作について、説明します。
注意
プライマリサーバの異常によって切り替えが発生してからスタンバイサーバの組込みを行うまで、データベースは多重化構成ではありません。できるだけ早急に異常原因を取り除き、組込みを行ってください。
スタンバイサーバで参照系の業務を行っていた場合、プライマリサーバに異常が発生してサーバが切り替わると、新しく切り替わったプライマリサーバに負荷が集中します。したがって、旧スタンバイサーバで行っている参照系の業務を一時停止して、旧プライマリサーバを新スタンバイサーバとして組込んだあと、新スタンバイサーバに対して参照系の業務を再開することを推奨します。
異常が発生した旧プライマリサーバを新スタンバイサーバとして組込む前に、新しく切り替わったプライマリサーバのインスタンスを停止した場合には、旧プライマリサーバのインスタンスから起動するとスプリットブレインが発生します。そのため、新プライマリサーバのインスタンスを起動してから、スタンバイサーバの再構築を行ってください。
切り替えが発生して縮退運転が行われている場合は、以下の運用操作を行って、スタンバイサーバを復旧してもとの状態に戻します。
これらの運用操作の流れを以下の図に示します。
図4.1 運用操作の流れ
以下の手順でリカバリを実施してください。
異常が発生した旧プライマリサーバに対して、mc_ctlコマンドをstopモードで実行します。
例)
> mc_ctl stop -M D:\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コマンドを実行する場合は、ソースサーバとターゲットサーバのタイムラインIDが異なっている必要があります。しかし、新プライマリサーバの昇格直後は、未適用の更新トランザクションログの適用処理とその後のチェックポイント処理によるタイムラインIDの更新処理が完了していないため、pg_rewindコマンドが実行できないことがあります。そのため、新プライマリサーバで、未適用の更新トランザクションログがなくなり、タイムラインIDの更新が完了してからpg_rewindコマンドを実行してください。
参照
pg_basebackupコマンドの詳細については、“PostgreSQL Documentation”の“Reference”の“pg_basebackup”を参照してください。
pg_rewindコマンドの詳細については、“PostgreSQL Documentation”の“Reference”の“pg_rewind”を参照してください。
pg_rewindコマンドを実行して、旧プライマリサーバのデータを新プライマリサーバと同期してリカバリする例を以下に示します。
旧プライマリサーバのインスタンスの起動
pg_ctlコマンドを使用して、旧プライマリサーバのインスタンスを起動します。
例)
> pg_ctl start -D D:\database\inst1
旧プライマリサーバのインスタンスの停止
pg_ctlコマンドを使用して、旧プライマリサーバのインスタンスを停止します。
例)
> pg_ctl stop -D D:\database\inst1
新プライマリサーバでの未適用更新トランザクションログの適用を待つ
新プライマリサーバで以下のSQLを実行し、結果がfalseになるまで待ちます。
# select pg_is_in_recovery();
例)
> psql -h 新プライマリサーバのホスト名 -p 新プライマリサーバのポート番号 -d データベース名 -c "select pg_is_in_recovery();"
接続するデータベースは、どのデータベースでも問題ありません。
注意
新プライマリサーバの昇格直後にpg_rewindを実行する場合、手順3および手順4の処理が必要になります。新プライマリサーバで更新系のSQLを実行できるようになり、チェックポイント処理が昇格後に実行されている場合は、手順3および手順4の処理は不要です。
タイムラインIDの更新
チェックポイント処理を実行して、タイムラインIDを更新します。
> psql -h 新プライマリサーバのホスト名 -p 新プライマリサーバのポート番号 -d データベース名 -c "checkpoint;"
接続するデータベースは、どのデータベースでも問題ありません。
旧プライマリサーバ(新スタンバイサーバ)に新プライマリサーバのインスタンスの複製を作成
pg_rewindコマンドを実行して、新スタンバイサーバのデータを新プライマリサーバと同期して作成します。
例)
> pg_rewind -D D:\database\inst1 --source-server="user=ユーザー名 host=新プライマリサーバのホスト名 port=新プライマリサーバのポート番号 dbname=データベース名"
旧プライマリサーバ(新スタンバイサーバ)のpostgresql.confファイルにパラメータを設定
スタンバイサーバ側に必要なパラメータをpostgresql.confファイルに設定します。
postgresql.confファイルに設定するパラメータは、“表2.5 設定するパラメータ”を参照して設定してください。
旧プライマリサーバ(新スタンバイサーバ)でstandby.signalファイルを作成
新プライマリサーバへストリーミングレプリケーションの接続を行うために、standby.signalファイルを作成してください。
postgresql.auto.confファイルのprimary_conninfoパラメータに指定する接続文字列を以下のように変更します。
キーワード | 指定内容 | 備考 |
---|---|---|
host | 新プライマリサーバのホスト名 | プライマリサーバに接続するための情報をPostgreSQLの接続文字列の形式で指定します。 |
port | 新プライマリサーバのポート番号 | |
application_name | 新スタンバイサーバ名 |
注意
host、portおよびapplication_name以外に設定が必要な接続文字列がある場合は、primary_conninfoパラメータの設定に含めてください。
primary_conninfoパラメータは、postgresql.confファイルには設定せず、postgresql.auto.confファイルのみに設定してください。
参照
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 D:\mcdir\inst1
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで-Fオプションを指定して実行します。
例)
> mc_ctl start -M D:\mcdir\inst1 -F
ポイント
自動切り替え/切り離しはMirroring Controllerが起動したあとに、mc_ctlコマンドのenable-failoverモード、または、disable-failoverモードを使用することにより自動切り替え/切り離しを有効、または無効にすることが可能です。
スタンバイサーバを組込んだあとにプライマリサーバとスタンバイサーバをもとの構成に戻したい場合は、プライマリサーバの切り戻しを行います。
以前のプライマリサーバで主な業務を行いたい場合に実施してください。
以下の手順で行います。
プライマリサーバの切り戻し
プライマリサーバとスタンバイサーバのどちらかでmc_ctlコマンドをswitchモードで実行します。
例)
> mc_ctl switch -M D:\mcdir\inst1
mc_ctlコマンドをswitchモードで実行したあとは、以下の状態になります。
例)
> mc_ctl status -M D:\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とインスタンスを停止します。
例)
> mc_ctl stop -M D:\mcdir\inst1
旧プライマリサーバ(新スタンバイサーバ)に新プライマリサーバのインスタンスの複製を作成
pg_basebackupコマンドを実行して、新スタンバイサーバのデータを新プライマリサーバと同期して作成します。
例)
> pg_basebackup -D D:\database\inst1 -X fetch --waldir=E:\transaction\inst1 --progress --verbose -R --dbname="application_name=スタンバイサーバ名" -h プライマリサーバのホスト名 -p プライマリサーバのポート番号
参照
新スタンバイサーバに新プライマリサーバのインスタンスを複製する手順は、新スタンバイサーバをセットアップする手順と同じです。
“2.5.2 スタンバイサーバのインスタンスの作成・設定・登録”を参照して、リカバリを実施してください。
スタンバイサーバの組込み
スタンバイサーバでMirroring Controllerとインスタンスを起動します。
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで実行します。
例)
> mc_ctl start -M D:\mcdir\inst1
インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで-Fオプションを指定して実行します。
例)
> mc_ctl start -M D:\mcdir\inst1 -F
ポイント
自動切り替え/切り離しはMirroring Controllerが起動したあとに、mc_ctlコマンドのenable-failoverモード、または、disable-failoverモードを使用することにより自動切り替え/切り離しを有効、または無効にすることが可能です。