運用センタでOSやミドルウェアのパッチ適用などの保守作業を行う場合は、センタ切り替えを行い、アプリケーション業務を待機センタに引き継ぐことで、保守作業中に業務を継続することができます。
保守作業の終了後は、必要に応じてセンタの切り戻しを行います。
注意
保守作業が予定時間を超えてしまうなどの原因で、待機センタでトランザクションログが再利用された場合には、ストリーミングレプリケーションの再開ができなくなります。その場合は、運用センタのインスタンスを再作成する必要があります。
運用センタ保守時のセンタ切り替えの手順を以下に示します。運用センタ保守時のセンタ切り替えの操作は、待機センタでデータベース多重化機能を利用する場合と利用しない場合で手順が異なります。
アプリケーション業務の停止
運用センタでのアプリケーション業務を停止します。
postgresql.confファイルの編集
運用センタのプライマリサーバにおいて、postgresql.confファイルのfollowing_async_walsendersパラメータを削除するか、またはoffを指定します。変更後、pg_ctlコマンドをreloadモードで実行し、設定変更を反映します。
参考
インスタンス停止時にもトランザクションログが生成されます。following_async_walsendersパラメータを有効化しておくと、インスタンス停止時に生成されたトランザクションログが待機センタへ反映されません。このため、インスタンス停止前にfollowing_async_walsendersパラメータを無効化しておきます。
インスタンスとMirroring Controllerの停止と自動起動・停止の無効化
運用センタのプライマリサーバとスタンバイサーバのインスタンス、およびMirroring Controllerを停止します。
mc_ctlコマンドを使用して、インスタンスとMirroring Controllerを同時に停止します。
Mirroring Controllerのサービスを停止したあと、インスタンスのサービスを停止します。
インスタンスとMirroring Controllerの自動起動・停止を設定している場合は、運用センタで有効化している設定を無効化します。
インスタンス状態の確認
運用センタのプライマリサーバのインスタンスが通常停止していることを確認します。
運用センタのプライマリサーバでpg_controldataコマンドを実行し、“Database cluster state”が“shut down”であることを確認します。
トランザクションログの位置を確認
待機センタの各サーバにトランザクションログが反映されていることを確認します。ログの反映状況は、以下の手順で確認します。
手順4で実行したpg_controldataコマンドの結果から“Latest checkpoint location”に出力されたLSNを確認します。
待機センタのプライマリ候補サーバ、およびスタンバイサーバでpg_last_wal_replay_lsn関数を実行し、実行結果のLSNが、手順aのLSNよりも新しいことを確認します。
ただし、手順bのLSNが手順aのLSNよりも新しくない場合、運用センタのプライマリサーバから待機センタへすべてのトランザクションログが反映されていないため、運用センタのインスタンスを再起動して、手順3から再度、操作を実施します。
Mirroring Controller裁定プロセスの停止と自動起動・停止の無効化
mc_arbコマンドを実行し、運用センタのMirroring Controller裁定プロセスを停止します。
mc_arbコマンド、またはWindowsサービスを使用して、運用センタのMirroring Controller裁定プロセスを停止します。
Mirroring Controller裁定プロセスの自動起動・停止を設定している場合は、運用センタで有効化している設定を無効化します。
保守作業の実施
運用センタで保守作業を開始します。
Mirroring Controllerの停止
待機センタのプライマリ候補サーバまたはスタンバイサーバで、mc_ctlコマンドのstopモードに-aオプションおよび--mc-onlyオプションを指定して実行し、待機センタのプライマリ候補サーバとスタンバイサーバのMirroring Controllerを停止します。
例)
> mc_ctl stop -M D:\mcdir\inst1 -a --mc-only
本手順の実施は不要です。
待機センタのサーバ定義ファイルの編集
待機センタのプライマリ候補サーバとスタンバイサーバのサーバ定義ファイルについて、以下のパラメータを変更します。
パラメータ | 変更内容 |
|---|---|
standbycenter_mode | パラメータをコメントアウトし、無効化してください。 |
primarycenter_primary_conninfo | |
standbycenter_primary_conninfo |
本手順の実施は不要です。
プライマリ候補サーバの昇格
pg_ctlコマンドをpromoteモードで実行し、待機センタのプライマリ候補サーバを昇格します。
例)
> pg_ctl promote -D D:\database\inst1
postgresql.confファイルの編集
本手順の実施は不要です。
プライマリ候補サーバとスタンバイサーバにおいて、postgresql.confファイルのrestart_after_crashパラメータにoffを指定し、pg_ctlコマンドをreloadモードで実行し、設定変更を反映します。
Mirroring Controller裁定プロセスの起動と自動起動・停止の有効化
本手順の実施は不要です。
mc_arbコマンドを実行し、待機センタのMirroring Controller裁定プロセスを起動します。
例)
$ mc_arb start -M /mcarb_dir/arbiter1
mc_arbコマンド、またはWindowsサービスを使用して、待機センタのMirroring Controller裁定プロセスを起動します。
例)
> mc_arb start -M D:\mcarb_dir\arbiter1
Mirroring Controller裁定プロセスの自動起動・停止を設定している場合は、待機センタで無効化している設定を有効化します。
Mirroring Controllerの起動
--mc-onlyオプションを指定したmc_ctlコマンド、またはWindowsサービスを使用して、待機センタのプライマリ候補サーバ、およびスタンバイサーバのMirroring Controllerのみを起動します。
例)
> mc_ctl start -M D:\mcdir\inst1 --mc-only
Mirroring Controllerの自動起動・停止の有効化
本手順の実施は不要です。
Mirroring Controllerの自動起動・停止を設定している場合は、待機センタで無効化している設定を有効化します。
アプリケーション業務の再開
待機センタのプライマリ候補サーバでアプリケーション業務を再開します。
postgresql.confファイルの編集
運用センタのプライマリサーバとスタンバイサーバのpostgresql.confファイルを編集します。指定するパラメータと内容は以下のとおりです。
パラメータ | 指定内容 |
|---|---|
restore_command | 'cmd /c ""インストールディレクトリ\\bin\\pgx_walcopy.cmd" "広域回線異常時の手動転送先の一時ディレクトリ\\%f" "%p""' |
archive_cleanup_command | ‘pg_archivecleanup "広域回線異常時の手動転送先の一時ディレクトリ" "%r"' |
ポイント
プライマリ候補サーバの切り替えの発生に備えて、プライマリ候補サーバとスタンバイサーバの両方にパラメータを設定します。
パラメータ | 指定内容 |
|---|---|
restart_after_crash | 本パラメータはoffのままでも問題ありませんが、削除するか、あるいは、onを指定することも可能です。 |
standby.signalファイルの作成
運用センタのプライマリサーバのデータ格納先ディレクトリに、standby.signalファイルを作成します。
参照
standby.signalファイルの詳細については、“PostgreSQL Documentation”の“Hot Standby”を参照してください。
運用センタのサーバ定義ファイルの編集
運用センタのプライマリサーバとスタンバイサーバのサーバ定義ファイルを編集し、運用センタを待機センタとして運用する設定を行います。指定するパラメータと内容は以下のとおりです。
パラメータ | 指定内容 | 備考 |
|---|---|---|
standbycenter_mode | primaryまたはstandby | 待機センタのプライマリ候補サーバとして運用するサーバにprimary、スタンバイサーバとして運用するサーバにstandbyを指定します。 |
primarycenter_primary_conninfo | 'host=待機センタ内のプライマリサーバのホスト名,スタンバイサーバのホスト名 port=待機センタ内のプライマリサーバのポート番号,スタンバイサーバのポート番号 application_name=運用センタのプライマリサーバ名 target_session_attrs=read-write …' | 待機センタのプライマリ候補サーバとして運用するサーバが、待機センタのプライマリサーバに接続するための情報をPostgreSQLの接続文字列の形式で指定します。 host、port、application_name、target_session_attrsの指定は必須です。 application_nameには、自サーバのpostgresql.auto.confファイルのprimary_conninfoパラメータで設定するapplication_nameの値と同じ値を設定します。 target_session_attrsにはread-writeを設定します。 |
standbycenter_primary_conninfo | 'host=運用センタ内の相手サーバのホスト名 port=運用センタ内の相手サーバのポート番号 application_name=運用センタのプライマリサーバ名 …' | 待機センタのスタンバイサーバとして運用するサーバが、待機センタのプライマリ候補サーバに接続するための情報をPostgreSQLの接続文字列の形式で指定します。 host、port、application_nameの指定は必須です。 application_name には、自サーバのpostgresql.auto.confファイルのprimary_conninfoパラメータで設定するapplication_nameの値と同じ値を設定します。 target_session_attrsを指定する場合はread-writeを設定しないでください。 |
注意
自動または手動による接続先切り替え時に、Mirroring Controllerがpostgresql.auto.confファイルのprimary_conninfoパラメータの設定値を以下のように変更します。そのため、必須の接続文字列以外に必要な情報がある場合は、primarycenter_primary_conninfoおよびstandbycenter_primary_conninfoパラメータに設定する接続文字列に含めてください。
待機センタの新プライマリ候補サーバのpostgresql.auto.confファイルのprimary_conninfoパラメータの設定を、サーバ識別子.confファイルのprimarycenter_primary_conninfoパラメータの設定で上書きします。
待機センタの新スタンバイサーバのpostgresql.auto.confファイルのprimary_conninfoパラメータの設定を、サーバ識別子.confファイルのstandbycenter_primary_conninfoパラメータの設定で上書きします。
自動または手動による接続先切り替えでは、Mirroring Controllerがサーバ識別子.confファイルのstandbycenter_modeの値を、新プライマリ候補サーバではprimaryに、新スタンバイサーバではstandbyに変更します。
postgresql.auto.confファイルのprimary_conninfoパラメータの設定と、サーバ識別子.confファイルのprimarycenter_primary_conninfoパラメータの設定は、プライマリ候補サーバ内で同じ値を指定してください。
本手順の実施は不要です。
インスタンスの起動
運用センタのプライマリサーバとスタンバイサーバでpg_ctlコマンドを実行し、インスタンスを起動します。
例)
> pg_ctl start -D D:\database\inst1
レプリケーションの接続先の変更
運用センタのプライマリサーバでALTER SYSTEM SET文を実行し、postgresql.auto.confファイルのprimary_conninfoパラメータに指定するストリーミングレプリケーションの接続先を待機センタのプライマリ候補サーバに変更します。
例) psqlコマンドを使用した場合の実行例を以下に示します。
postgres=# ALTER SYSTEM SET primary_conninfo='host=待機センタのプライマリ候補サーバのホスト名,待機センタのスタンバイサーバのホスト名 port=待機センタのプライマリ候補サーバのポート番号,待機センタのスタンバイサーバのポート番号 application_name=運用センタのプライマリサーバ名 target_session_attrs=read-write';
レプリケーションの接続先の変更
運用センタのスタンバイサーバでALTER SYSTEM SET文を実行し、postgresql.auto.confファイルのprimary_conninfoパラメータに指定するストリーミングレプリケーションの接続先を運用センタのプライマリサーバに変更します。
例) psqlコマンドを使用した場合の実行例を以下に示します。
postgres=# ALTER SYSTEM SET primary_conninfo='host=運用センタのプライマリサーバのホスト名 port=運用センタのプライマリサーバのポート番号 application_name=運用センタのスタンバイサーバ名';
インスタンスの停止
運用センタのプライマリサーバとスタンバイサーバでpg_ctlコマンドを実行し、インスタンスを停止します。
例)
> pg_ctl stop -D D:\database\inst1
Mirroring Controller裁定プロセスの起動と自動起動・停止の有効化
mc_arbコマンドを実行し、運用センタのMirroring Controller裁定プロセスを起動します。
例)
$ mc_arb start -M /mcarb_dir/arbiter1
mc_arbコマンド、またはWindowsサービスを使用して、運用センタのMirroring Controller裁定プロセスを起動します。
例)
> mc_arb start -M D:\mcarb_dir\arbiter1
Mirroring Controller裁定プロセスの自動起動・停止を設定している場合は、運用センタで無効化している設定を有効化します。
本手順の実施は不要です。
Mirroring Controllerの起動と自動起動・停止の有効化
mc_ctlコマンドまたはWindowsサービスを使用して、運用センタのプライマリサーバ、およびスタンバイサーバのインスタンスとMirroring Controllerを起動します。
例)
> mc_ctl start -M D:\mcdir\inst1
インスタンスとMirroring Controllerの自動起動・停止を設定している場合は、運用センタで無効化している設定を有効化します。
本手順の実施は不要です。
インスタンスの起動
本手順の実施は不要です。
startモードを指定したpg_ctlコマンド、またはWindowsサービスを使用して、運用センタのプライマリサーバとスタンバイサーバのインスタンスを起動します。
注意
保守運用中は、運用センタが一時的に待機センタの役割を担うため、Mirroring Controllerは起動しないでください。
postgresql.confファイルの編集
待機センタのプライマリ候補サーバのpostgresql.confファイルに以下のパラメータを設定します。設定後、pg_ctlコマンドをreloadモードで実行し、設定変更を反映します。
パラメータ | 指定内容 |
|---|---|
following_async_walsenders | 'on (運用センタのプライマリサーバ名, 運用センタのスタンバイサーバ名)' |
注意
host、port、application_name、target_session_attrs以外に必要な接続文字列がある場合は、postgresql.auto.confファイルのprimary_conninfoパラメータの設定に含めてください。
ポイント
postgresql.auto.confファイルのprimary_conninfoパラメータのtarget_session_attrsにread-writeを指定することで、待機センタのプライマリ候補サーバがhostおよびportパラメータに指定する接続先情報の中から運用センタのプライマリサーバを自動で認識します。運用センタでの切り替え発生時に、待機センタのプライマリ候補サーバが自動的に運用センタの新プライマリサーバに接続できるように、primarycenter_primary_conninfoパラメータのhostおよびportには、運用センタのプライマリサーバとスタンバイサーバの両方を接続先情報として指定してください。
参照
primary_conninfoの詳細については、“PostgreSQL Documentation”の“Setting Up a Standby Server”を参照してください。
運用センタ保守後に行うセンタの切り戻しの手順は、“9.3.1.1 運用センタ保守時のセンタ切り替え”の手順と同じです。このため、センタ切り替えの手順の運用センタと待機センタを読み替えて参照してください。
ポイント
センタ切り戻しを速やかに行うために、保守運用中に待機センタに蓄積されたトランザクションログが運用センタへ適用されて収束していることを確認してから行います。運用センタのトランザクションログの収束状況は、待機センタのプライマリ候補サーバで実行したバックアップ制御関数pg_current_wal_lsnの結果と運用センタのプライマリサーバで実行したリカバリ情報関数pg_last_wal_receive_lsnの結果の差分から確認することができます。
