待機センタでOSやミドルウェアのパッチ適用などの保守作業の手順は、待機センタでデータベース多重化機能を利用する場合と利用しない場合で異なります。なお、待機センタの裁定サーバの保守の手順は、データベース多重化運用の手順と同じです。詳細は、“3.8.3 裁定サーバの保守”を参照してください。
待機センタでデータベース多重化機能を利用する場合
待機センタの運用を停止して保守作業を行う場合と運用を継続しながら保守作業を行う場合で手順が異なります。
待機センタで保守停止を行った後に行います。保守停止の手順は、データベース多重化運用と同じです。詳細は、“3.8.2 保守停止”を参照してください。保守作業が完了した後、保守停止により停止したMirroring Controller裁定プロセス、インスタンス、およびMirroring Controllerを再起動してください。
待機センタでの運用を継続しながら保守作業を行う場合は、ローリングアップデートの手順を実施します。待機センタのローリングアップデートの手順は、基本的にはデータベース多重化運用の手順と同じです。詳細は、“3.8.1 ローリングアップデート”を参照してください。以下はデータベース多重化運用の手順との相違点です。
“スタンバイサーバの保守作業”の手順4において、pg_basebackupによるプライマリ候補サーバとのデータの同期は必須ではありません。
“プライマリサーバに切り替え”において、待機センタでは新プライマリ候補サーバのpostgresql.confファイルのsynchronous_standby_namesパラメータはコメントアウトされません。
“新スタンバイサーバの保守作業”の手順4において、pg_basebackupによるプライマリ候補サーバとのデータの同期は必須ではありません。
“新スタンバイサーバの保守作業”の手順6において、postgresql.confファイルのsynchronous_standby_namesパラメータの編集は不要です。
“プライマリサーバの切り戻し”の手順は、“9.1.5 プライマリ候補サーバの切り戻し”を参照してください。
待機センタでデータベース多重化機能を利用しない場合
待機センタでOSやミドルウェアのパッチ適用などの保守作業は、待機センタのプライマリ候補サーバとスタンバイサーバのインスタンスを停止した後に行います。
保守作業が完了した後、停止したインスタンスを再起動してください。
注意
待機センタの保守作業時間が予定していた時間を越える場合、運用センタでトランザクションログが再利用され、ストリーミングレプリケーションの再開ができなくなります。その場合は、待機センタのインスタンスを再作成する必要があります。待機センタのセットアップについては、“7.3 待機センタのセットアップ”を参照してください。
参照
災害対策運用時のトランザクションログの容量の見積もりについては、“導入ガイド(サーバ編)”の“災害対策運用時のトランザクションログの容量の見積り”を参照してください。
