7.6.1 ローリングアップデート

データベース多重化運用では、業務を継続しながら構成されたサーバの保守作業を行うローリングアップデートを実施できます。

まず、スタンバイサーバに対して保守作業を実施したあと、スタンバイサーバをプライマリサーバに切り替えます。次に、スタンバイサーバに切り替わった旧プライマリサーバに対して保守作業を実施することで、業務を継続しながら保守作業を行うことができます。

参照

スタンバイサーバへの保守作業で停止時間が長くなる場合は、“7.7.1 スタンバイサーバの停止を伴う変更”の“スタンバイサーバの停止時間”を参照してください。

以下は、ローリングアップデートのイメージです。

図7.1 ローリングアップデート

上図に対応して、以下の手順で行います。

スタンバイサーバの保守作業
1. スタンバイサーバにおいてサーバの保守作業を行うために、Mirroring Controllerを停止します。
  事前に自動起動・停止の設定を行った状態で保守作業のためにサーバの電源を停止する場合は、OSのシャットダウン時に自動的に停止します。したがって、本手順は不要です。
```
例)
```
```
$ mc_ctl stop -M /mcdir/inst1
```
2. 停止が完了したことを確認します。
  スタンバイサーバにおいてデータベースサーバのOSの起動・停止に合わせて、多重化したインスタンスを自動的に起動・停止する設定にしていた場合は、自動的に起動・停止する設定を解除します。
  参照
  OSの起動・停止に合わせて、多重化したインスタンスを自動的に起動・停止する設定の詳細は“6.11 多重化したインスタンスとMirroring Controllerの自動起動・停止の設定”を参照してください。
  OSのスーパーユーザーで、chkconfigコマンドを使用して自動起動・停止の無効化を行います。
  以下は、自動起動・停止のシェルスクリプトを“rc_mc_inst1”として作成して、ラン・レベル3と5に対して無効化した場合の例です。
```
例)
```
```
# chkconfig --level 35 rc_mc_inst1 off
```
3. 保守作業を実施します。
4. スタンバイサーバにプライマリサーバのインスタンスの複製を作成します。
  1. インスタンスの格納先ディレクトリ内の削除
    OSのコマンドを使用して、スタンバイサーバのインスタンスのデータ格納先ディレクトリ配下の資源を削除します。ディレクトリは削除しないでください。
  2. テーブル空間の格納先ディレクトリの削除
    テーブル空間の格納先がインスタンスのデータ格納先ディレクトリ配下以外に配置されている場合は、OSのコマンドを使用して、スタンバイサーバのテーブル空間の格納先ディレクトリ配下の資源を削除します。ディレクトリは削除しないでください。
  3. pg_basebackupコマンドによるインスタンスの同期
    pg_basebackupコマンドの出力先のディレクトリにスタンバイサーバのインスタンスの格納先ディレクトリを指定して実行します。これにより、インスタンスを同期します。
```
例)
```
```
$ pg_basebackup -D /database/inst1 --xlog --progress --verbose -h プライマリサーバのIPアドレス -p プライマリサーバのポート番号
```
    注意
    プライマリサーバのインスタンスのデータ格納先ディレクトリ配下において、pg_xlogディレクトリなどを負荷分散のためにシンボリックリンクを作成して運用している場合、pg_basebackupコマンドの実行ではシンボリックリンクを複製しません。
    pg_basebackupコマンドの実行が正常終了したあと、スタンバイサーバにおいてシンボリックリンクを作成しなおしてください。
  4. recovery.confファイルの編集
    recovery.doneファイルが存在する場合は、recovery.confファイルにリネームしてprimary_conninfoパラメータを編集します。
    recovery.doneファイルが存在しない場合は、recovery.confファイルを作成してください。
  5. porstgresql.confファイルの編集
    インスタンスの複製により、synchronous_standby_namesパラメータの内容がプライマリサーバでの指定内容になるため、スタンバイサーバでの指定内容に修正します。コメントアウトされている場合は、アンコメントしてください。
  参照
  スタンバイサーバにプライマリサーバのインスタンスを複製する手順は、スタンバイサーバをセットアップする手順と同じです。
  “6.4 スタンバイサーバのインスタンスの作成・設定・登録”を参照して、リカバリを実施してください。
5. 多重化したインスタンスを自動的に起動・停止する設定を確認します。
  手順2において、OSの起動・停止に合わせて、多重化したインスタンスを自動的に起動・停止する設定を解除した場合は、再設定します。自動的に起動・停止する必要が無い場合は、この手順は省略できます。
  OSのスーパーユーザーで、chkconfigコマンドを使用してシェルスクリプトの有効化を行います。
  以下は、自動起動・停止のシェルスクリプトを“rc_mc_inst1”として作成して、ラン・レベル3と5に対して有効化した場合の例です。
```
例)
```
```
# chkconfig --level 35 rc_mc_inst1 on
```
6. スタンバイサーバのMirroring Controllerを起動（組込み）します。
  本操作はスタンバイサーバでの保守作業を確定するうえで必要であるため、必ず実施してください。
  Mirroring Controllerオプションを使用する場合
  インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードでfオプションを指定して実行します。これにより、自動切り替え/切り離しの有効化を行います。
  なお、fオプションを指定せずに起動した場合、自動切り替え/切り離しは有効になりません。有効にするには、Mirroring Controllerを起動したあとにmc_ctlコマンドをenable-failoverモードで実行するか、fオプションを指定してMirroring Controllerを再起動してください。
```
例)
```
```
$ mc_ctl start -M /mcdir/inst1 -f
```
  Mirroring Controllerオプションを使用しない場合
  インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードで実行します。
```
例)
```
```
$ mc_ctl start -M /mcdir/inst1
```
プライマリサーバに切り替え
プライマリサーバの保守を行うために、プライマリサーバとスタンバイサーバのどちらかでmc_ctlコマンドをswitchモードで実行します。
```
例)
```
```
$ mc_ctl switch -M /mcdir/inst1
```
切り替えが完了した時点で、新プライマリサーバのpostgresql.confファイルのsynchronous_standby_namesパラメータが以下のようにコメントアウトされます。
```
例)
```
```
#synchronous_standby_names = 'primary'
```
新スタンバイサーバの保守作業
1. Mirroring Controllerを停止します。
  新スタンバイサーバ（切り替わる前のプライマリサーバ）において、mc_ctlコマンドをstopモードで実行します。
```
例)
```
```
$ mc_ctl stop -M /mcdir/inst1
```
2. 停止が完了したことを確認します。
  新スタンバイサーバにおいてデータベースサーバのOSの起動・停止に合わせて、多重化したインスタンスを自動的に起動・停止する設定にしていた場合は、ここで自動的に起動・停止する設定を解除します。
  参照
  OSの起動・停止に合わせて、多重化したインスタンスを自動的に起動・停止する設定の詳細については“6.11 多重化したインスタンスとMirroring Controllerの自動起動・停止の設定”を参照してください。
  OSのスーパーユーザーで、chkconfigコマンドを使用して自動起動・停止の無効化を行います。
  以下は、自動起動・停止のシェルスクリプトを“rc_mc_inst1”として作成して、ラン・レベル3と5に対して無効化した場合の例です。
```
例)
```
```
# chkconfig --level 35 rc_mc_inst1 off
```
3. 停止中の新スタンバイサーバにおいて、保守作業を実施します。
4. 新スタンバイサーバに新プライマリサーバのインスタンスの複製を作成します。
  1. インスタンスの格納先ディレクトリ内の削除
    OSのコマンドを使用して、新スタンバイサーバのインスタンスのデータ格納先ディレクトリ配下の資源を削除します。ディレクトリは削除しないでください。
  2. テーブル空間の格納先ディレクトリの削除
    テーブル空間の格納先がインスタンスのデータ格納先ディレクトリ配下以外に配置されている場合は、OSのコマンドを使用して、新スタンバイサーバのテーブル空間の格納先ディレクトリ配下の資源を削除します。ディレクトリは削除しないでください。
  3. pg_basebackupコマンドによるインスタンスの同期
    pg_basebackupコマンドの出力先のディレクトリに新スタンバイサーバのインスタンスのデータ格納先ディレクトリを指定して実行します。これにより、インスタンスを同期します。
```
例)
```
```
$ pg_basebackup -D /database/inst1 --xlog --progress --verbose -h 新プライマリサーバのIPアドレス -p 新プライマリサーバのポート番号
```
    注意
    新プライマリサーバのインスタンスのデータ格納先ディレクトリ配下において、pg_xlogディレクトリなどを負荷分散のためにシンボリックリンクを作成して運用している場合、pg_basebackupコマンドの実行ではシンボリックリンクを複製しません。
    pg_basebackupコマンドの実行が正常終了したあと、新スタンバイサーバにおいてシンボリックリンクを作成しなおしてください。
  4. recovery.confファイルの編集
    recovery.doneファイルが存在する場合は、recovery.confファイルにリネームしてprimary_conninfoパラメータを編集します。
    recovery.doneファイルが存在しない場合は、recovery.confファイルを作成してください。
  5. porstgresql.confファイルの編集
    インスタンスの複製により、synchronous_standby_namesパラメータの内容がプライマリサーバでの指定内容になるため、スタンバイサーバでの指定内容に修正します。コメントアウトされている場合は、アンコメントしてください。
  参照
  スタンバイサーバにプライマリサーバのインスタンスを複製する手順は、スタンバイサーバをセットアップする手順と同じです。
  “6.4 スタンバイサーバのインスタンスの作成・設定・登録”を参照して、リカバリを実施してください。
5. 多重化したインスタンスを自動的に起動・停止する設定を確認します。
  手順2において、OSの起動・停止に合わせて、多重化したインスタンスを自動的に起動・停止する設定を解除した場合は、ここで再設定します。自動的に起動・停止する必要が無い場合は、この手順は省略することができます。
  OSのスーパーユーザーで、chkconfigコマンドを使用してシェルスクリプトの有効化を行います。
  以下は、自動起動・停止のシェルスクリプトを“rc_mc_inst1”として作成し、ラン・レベル3と5に対して有効化した場合の例です。
```
例)
```
```
# chkconfig --level 35 rc_mc_inst1 on
```
6. 保守作業が完了したあと、スタンバイサーバのpostgresql.confファイルを必要に応じて編集します。
  インスタンスの複製により、synchronous_standby_namesパラメータがプライマリサーバでの指定内容になるため、スタンバイサーバでの指定内容へ修正します。コメントアウトされている場合は、アンコメントしてください。
7. スタンバイサーバで、Mirroring Controllerを起動（組込み）します。
  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
```
  Mirroring Controllerオプションを使用しない場合
  インスタンス管理者ユーザーで、mc_ctlコマンドをstartモードでwオプションを指定して実行します。
```
例)
```
```
$ mc_ctl start -M /mcdir/inst1 -w
```
8. プライマリサーバの切り戻しを行います。
  プライマリサーバとスタンバイサーバをもとのサーバ構成に戻して、以前のプライマリサーバで主たる業務を行いたい場合に実施してください。手順の詳細は、“8.1.1.3 プライマリサーバの切り戻し”を参照してください。

注意

保守作業が完了したあと、すみやかにバックアップを取得してください。