[Linux] PostgreSQL Recovery Kit の処理概要

対象製品
PostgreSQL Recovery Kit (LifeKeeper for Linux)
※本処理概要は LifeKeeper for Linux v9.0.0に付属するリカバリキットをもとに作成しています。

起動処理
起動処理においてはタイムアウトが設けられており、この時間を超過してもPostgreSQLリソースの起動処理が完了しない場合、
起動処理は失敗終了となります。

起動処理におけるタイムアウトは下記の通り、複数のパラメータと計算式から決定されます。

 (LKPGSQL_CONN_RETRIES * 5) + (3 * LKPGSQL_STATUS_TIME) + (LKPGSQL_ACTION_RETRIES * 2)
 ※それぞれのパラメータについては後述している「関連パラメータ」のURL先をご参照ください。

参考情報:PostgreSQLリソースに関わる全てのパラメータがデフォルトの場合、起動処理のタイムアウトは146秒です。

1) 稼働状態の確認

 監視処理と同一の項目を確認し、PostgreSQLの稼働状態を確認します。

 本項目において起動状態にあると判断された場合、以降の起動操作は実施せずに起動処理は成功となります。

 本項目において停止状態にあると判断された場合、以降の起動操作を実施します。

2) PostgreSQLの起動および起動状態の確認

 2-1) pg_ctlコマンドを通じた起動および起動状態の確認その1
  本項目はPostgreSQLが起動状態と判定されるまで、最大でLKPGSQL_ACTION_RETRIESに指定された回数まで繰り返します。

  起動時コマンドラインはpostgresql.confのlisten_adressesの設定により異なります。

   ・パラメータ筆頭がIPアドレス
    # su – postgres -c pg_ctl -D <データディレクトリ> -o “-k <ソケットディレクトリ> -p <ポート番号>” -l <ログファイル> start

   ・パラメータ筆頭がホスト名
    # su – postgres -c pg_ctl -D <データディレクトリ> -o “-i -k <ソケットディレクトリ> -p <ポート番号>” -l <ログファイル> start

  ※より具体的な条件は後述の関連情報項に記載のリンクに記事がございます。

  2秒(固定)待機した後に1回目の確認として監視処理と同一の項目を確認し、PostgreSQLが起動状態にあることを確認します。

  上記1回目の確認において起動状態にあると判断された場合、以降の処理は実施せずに起動処理は成功終了します。

  上記1回目の確認において起動状態にないと判断された場合、PIDファイルが存在していればさらに2秒(固定)待機した後、
  再度2回目として監視項目と同一の項目を確認し、PostgreSQLが起動状態にあることを確認します。

  上記2回目の確認において起動状態にあると判断された場合、以降の処理は実施せずに起動処理は成功終了します。

  上記2回目の確認において起動状態にないと判断された場合、本項目2-2) を最初から実施します。

 2-2) 起動状態の確認その2
  上述の2-1)で起動状態を確認できない場合、以下のコマンドラインを用いて起動状態の確認を実施します。

   # su – postgres -c “sh -c LANG=C pg_ctl -D <データディレクトリ> status”

  上記コマンドラインの出力に”not running”や”no server running”が含まれる場合、
  またはコマンドラインの戻り値が0以外の場合、以降の処理は実施せずに起動処理は失敗終了します。

  上記コマンドラインの出力に異常がなく、戻り値が0の場合は以降2-3)の処理を実施します。

 2-3) 起動状態の確認その3
  本項目はPostgreSQLが起動状態と判定されるまで、最大でLKPGSQL_CONN_RETRIESに指定された回数まで繰り返します。

  監視処理と同一の項目を確認し、PostgreSQLの稼働状態を確認します。

  上記確認において起動状態にあると判断された場合、以降の処理は実施せずに起動処理は成功終了します。

  上記確認において停止状態にあると判断された場合、5秒(固定)待機した後に本項目2-3)を最初から実施します。

 2-4) 起動状態の確認その4
  上述の2-3)で起動状態を確認できない場合、以下のコマンドラインを用いて起動状態の確認を実施します。

   # su – postgres -c “sh -c LANG=C pg_ctl -D <データディレクトリ> status”

  上記コマンドラインの出力に”not running”や”no server running”が含まれる場合、
  またはコマンドラインの戻り値が0以外の場合、以降の処理は実施せずに起動処理は失敗終了します。

  上記コマンドラインの出力に異常がなく戻り値が0の場合、起動処理は成功終了します。

停止処理
停止処理においてはタイムアウトが設けられており、この時間を超過してもPostgreSQLリソースの停止処理が完了しない場合、
停止処理は失敗終了となります。

停止処理におけるタイムアウトは下記の通り、複数のパラメータと計算式から決定されます。

 (LKPGSQL_CONN_RETRIES * 5) + (3 * LKPGSQL_STATUS_TIME) + (LKPGSQL_ACTION_RETRIES * 2)

参考情報:PostgreSQLリソースに関わる全てのパラメータがデフォルトの場合、停止処理のタイムアウトは146秒です。

1) 稼働状態の確認

 監視処理と同一の項目を確認し、PostgreSQLの稼働状態を確認します。

 本項目において停止状態にあると判断された場合、以降の停止操作は実施せずに停止処理は成功終了します。

 本項目において起動状態にあると判断された場合、以降の停止操作を実施します。

2) PostgreSQLの停止および停止状態の確認

 2-1) pg_ctlコマンドを通じた停止
  本項目ではLKPGSQL_SDIRSおよびLKPGSQL_IDIRSパラメータの設定に基づき、
  保護対象のデータディレクトリに対し、オプションを指定してPostgreSQLの停止操作を実施します。

  ・何れのパラメータにも指定されていないデータディレクトリ
   # su – postgres -c pg_ctl -m fast -D <データディレクトリ> -o “-k <ソケットディレクトリ> -p <ポート番号>” -l <ログファイル> stop

  ・LKPGSQL_SDIRSへ指定されたデータディレクトリ
   # su – postgres -c pg_ctl -m smart -D <データディレクトリ> -o “-k <ソケットディレクトリ> -p <ポート番号>” -l <ログファイル> stop

  ・LKPGSQL_IDIRSへ指定されたデータディレクトリ
   # su – postgres -o pg_ctl -m immediate -D <データディレクトリ> -o “-k <ソケットディレクトリ> -p <ポート番号>” -l <ログファイル> stop

  ※両パラメータに同一のデータディレクトリを指定した場合は、LKPGSQL_IDIRSパラメータが優先されます。

  なお、上記停止コマンド実行結果を実行元で受理した後、”2 * LKPGSQL_KILLPID_TIME”秒の待機を実施します。

 2-2) PostgreSQLに対する強制停止
  上述の2-1)にて停止コマンドが失敗していた場合、以下の手順にてPostgreSQLに対する強制停止を実施します。

   1. pg_ctlコマンドおよびimmediateオプションを用いた停止(コマンドラインおよび実行後の待機時間は上述のものと同じ)
   2. 全てのpostgresプロセスに対するSIGTERM(15)の発行
   3. 2秒(固定)の待機
   4. 全てのpostgresプロセスに対するSIGKILL(9)の発行

  ※上記処理については成功の有無は評価されません。

 2-3) 停止状態の確認
  監視処理と同一の項目を確認し、PostgreSQLの稼働状態を確認します。

  本項目において停止状態にあると判断された場合、以降の処理は実施せずに停止処理は成功終了します。

  本項目において起動状態にあると判断された場合、以降の処理を実施します。

 2-4) postmasterプロセスの強制停止
  本項目はpostmasterプロセスが停止したと判断されるまで最大でLKPGSQL_ACTION_RETRIESに指定された回数まで繰り返します。

  下記netstatコマンドの出力からpostmasterプロセスのIDを取得します。

   # netstat -anp | grep postmaster | grep unix

  上記netstatコマンドからpostmasterプロセスのIDを特定できない場合は、PIDファイルからプロセスIDを取得します。

  上記何れでもpostmasterのプロセスIDが取得されない場合、postmasterプロセスは停止状態にあると判断し、
  次項2-5)の処理へ移行します。プロセスIDが取得された場合は、処理を続行します。

  全てのpostgresプロセスに対してSIGTERM(15)を発行します。

  先のnetstatまたはpsから取得したpostmasterのプロセスに対してSIGTERM(15)を発行し、
  成功すれば次項2-5)の処理へ移行します。失敗した場合、1秒(固定)待機の後に本項目を最初から実施します。

 2-5) postmasterプロセス強制停止後の確認

  下記netstatコマンドの出力からpostmasterプロセスのIDを取得します。

   # netstat -anp | grep postmaster | grep unix

  上記netstatコマンドからpostmasterプロセスのIDを特定できない場合は、PIDファイルからプロセスIDを取得します。

  上記何れかでpostmasterのプロセスIDが取得された場合、PostgreSQLを停止できなかったとして停止処理は失敗終了します。
  プロセスIDが取得されない場合、PostgreSQLは停止状態にあると判断し、次項2-6)の処理へ移行します。

 2-6) postmasterプロセス強制停止後の後処理
  SOCKETファイルおよびPIDファイルが残存している場合、各ファイルの削除を実施の上、停止処理は成功終了します。

監視処理
監視処理においてはタイムアウトが設けられており、この時間を超過してもPostgreSQLリソースの監視処理が完了しない場合、
監視処理は失敗終了となり回復処理(hangrecover)が実施されます。

監視処理におけるタイムアウトはLKPGSQL_STATUS_TIMEに設定されます。
なお、上記パラメータがLKCHECKINTERVALよりも大きい場合、”LKCHECKINTERVAL / 60″がタイムアウトの値となります。

参考情報:PostgreSQLリソースに関わる全てのパラメータがデフォルトの場合、監視処理のタイムアウトは26秒です。

1) ポート番号及びプロセスIDの確認

 1-1) ポート番号の確認
  稼働中のpostmasterプロセスのポート番号がリソースで保持している情報と一致するか確認します。
  稼働中のPostgreSQLのポート番号は以下のコマンドラインの出力から確認します。

   # su – postgres -c pg_ctl -D <データディレクトリ> status

  以下の様な事象が発生した場合、本項目1)では下記の状態として扱い後述の2)の処理へ移行します。

   ・上記コマンドラインからステータスを取得できない
    →「ステータス取得不可」

   ・上記コマンドラインからポート番号を取得できない
    →「ポート番号取得不可」

  上記コマンドラインの出力から取得したポート番号とリソースで保持している情報が一致する場合、
  次項1-2)の処理へ移行します。
  上記コマンドラインの出力から取得したポート番号とリソースで保持している情報が一致しない場合、
  本項目1)では「停止状態」として扱い、後述の2)の処理へ移行します。

 1-2) プロセスIDの確認
  a) netstatコマンドの出力からpostmasterプロセスのIDを取得します。

   # netstat -anp | grep postmaster | grep unix

  b) PIDファイルからプロセスIDを取得します。

  上記a),b)で取得したプロセスIDが一致する場合、本項目1)では「稼働状態」として扱い、後述の2)の処理へ移行します。
  上記a),b)で取得したプロセスIDが一致しない場合、本項目1)では「停止状態」として扱い、後述の2)の処理へ移行します。

2) PostgreSQLへの接続性確認

 2-1) template1データベースへの接続性確認
  postgresユーザとして以下のコマンドラインを用いてtemplate1データベースへの接続性を確認します。

   $ psql -h <ソケット> -p <ポート番号> -U -c \dS -d template1

  template1データベースへの接続に成功した場合、本項目2)では「接続成功」として扱い、後述の3)の処理へ移行します。
  template1データベースへの接続に失敗した場合、次項2-2)の処理へ移行します。

 2-2) PostgreSQLサーバへの接続性確認
  postgresユーザとして以下のコマンドラインを用いてPostgreSQLサーバへの接続性を確認します。

   $ psql -h <ソケット> -p <ポート番号> -U -l

  サーバへの接続に成功した場合、本項目2)では「接続成功」として扱い、後述の3)の処理へ移行します。
  サーバへの接続に失敗した場合、本項目2)では「接続失敗」として扱い、後述の3)の処理へ移行します。

3) 稼働状態の簡易確認
  以下のコマンドラインを用いて起動状態の確認を実施します。

   # su – postgres -c “sh -c LANG=C pg_ctl -D <データディレクトリ> status”

  上記コマンドラインの出力に”not running”や”no server running”が含まれる場合、
  またはコマンドラインの戻り値が0以外の場合、本項目3)では「停止状態」として扱い、後述の4)の処理へ移行します。

  上記コマンドラインの出力に異常がなく戻り値が0の場合、本項目3)では「起動状態」として扱い、後述の4)の処理へ移行します。

4) プロセスIDの取得
 PIDファイルからプロセスIDを取得し、後述の5)の処理へ移行します。

5) 稼働状態の判定
 以下の条件をもとに稼働状態を判定します。なお、評価順序は記載順のとおりです。

  条件1) 本条件にあてはまる場合、以降の処理は実施せずに監視処理は失敗終了となり回復処理(dbfail)が実施されます。

   ・上述の項目1)の結果が「稼働状態」以外である。
    →すなわち「NOT 稼働状態」である。

   ・上述の項目2)の結果が「接続成功」かつ、上述の項目3)の結果が「起動状態」でない。
    →すなわち「NOT (接続成功 AND 起動状態)」である。

  条件2) 本条件にあてはまる場合、以降の処理は実施せずに監視処理は成功終了します。
   ・上述の項目1)の結果が「稼働状態」である。
   ・上述の項目2)の結果が「接続成功」である。
   ・上述の項目3)の結果が「起動状態」である。

 上記の条件1)および条件2)のいずれにもあてはまらない場合、以降の処理を実施します。

 上述の項目4)においてプロセスIDを取得できていない場合、監視処理は失敗終了となり回復処理(dbfail)が実施されます。
 上述の項目4)においてプロセスIDを取得できている場合、監視処理は成功終了となります。

回復処理(hangrecover)
回復処理においてはタイムアウトが設けられており、この時間を超過してもPostgreSQLリソースの回復処理が完了しない場合、
回復処理は失敗としてリソース障害となりフェイルオーバに至ります。

回復処理におけるタイムアウトは下記の通り、複数のパラメータと計算式から決定されます。

 2 * ((LKPGSQL_CONN_RETRIES * 5) + (3 * LKPGSQL_STATUS_TIME) + (LKPGSQL_ACTION_RETRIES * 2))

参考情報:PostgreSQLリソースに関わる全てのパラメータがデフォルトの場合、回復処理のタイムアウトは292秒です。

1) postgresプロセスの強制停止

 全てのpostgresプロセスに対するSIGTERM(15)を発行します。

2) postmasterプロセスの強制停止その1
 2-1) postmasterプロセスの強制停止
  本項目はpostmasterプロセスが停止したと判断されるまで最大でLKPGSQL_ACTION_RETRIESに指定された回数まで繰り返します。

  下記netstatコマンドの出力からpostmasterプロセスのIDを取得します。

   # netstat -anp | grep postmaster | grep unix

  上記netstatコマンドからpostmasterプロセスのIDを特定できない場合は、PIDファイルからプロセスIDを取得します。

  上記何れでもpostmasterのプロセスIDが取得されない場合、postmasterプロセスは停止状態にあると判断し、
  次項2-5)の処理へ移行します。プロセスIDが取得された場合は、処理を続行します。

  全てのpostgresプロセスに対してSIGTERM(15)を発行します。

  先のnetstatまたはpsから取得したpostmasterのプロセスに対してSIGTERM(15)を発行し、
  成功すれば次項2-2)の処理へ移行します。失敗した場合、1秒(固定)待機の後に本項目を最初から実施します。

 2-2) postmasterプロセス強制停止後の確認

  下記netstatコマンドの出力からpostmasterプロセスのIDを取得します。

   # netstat -anp | grep postmaster | grep unix

  上記netstatコマンドからpostmasterプロセスのIDを特定できない場合は、PIDファイルからプロセスIDを取得します。

  上記何れかでpostmasterのプロセスIDが取得された場合、
  PostgreSQLを停止できなかったとして本項目2)は「失敗」として後述の3)の処理へ移行します。
  プロセスIDが取得されない場合、PostgreSQLは停止状態にあると判断し、次項2-3)の処理へ移行します。

 2-3) postmasterプロセス強制停止後の後処理
  SOCKETファイルおよびPIDファイルが残存している場合、各ファイルの削除を実施の上、
  本項目2)は「成功」として後述の4)の処理へ移行します。

3) postmasterプロセスの強制停止その2
 上述の項目2)においてpostmasterプロセスの強制停止に失敗した場合に本項3)が実施されます。

 下記netstatコマンドの出力からpostmasterプロセスのIDを取得します。

  # netstat -anp | grep postmaster | grep unix

 上記netstatコマンドからpostmasterプロセスのIDを特定できない場合は、PIDファイルからプロセスIDを取得します。

 上記何れかでpostmasterのプロセスIDが取得された場合、当該プロセスに対しSIGKILL(9)を発行の上、
 LKPGSQL_KILLPID_TIMEに指定された時間待機し次項4)の処理へ移行します。

 上記何れでもpostmasterのプロセスIDが取得されない場合、
 LKPGSQL_KILLPID_TIMEに指定された時間待機し次項4)の処理へ移行します。

4) PostgreSQLの起動処理
 起動処理の項目2)と同一の処理にてPostgreSQLの起動を実施します。
 本処理の結果をもって本回復処理(hangrecover)の成功の有無を決定します。

回復処理(dbfail)
回復処理においてはタイムアウトが設けられており、この時間を超過してもPostgreSQLリソースの回復処理が完了しない場合、
回復処理は失敗としてリソース障害となりフェイルオーバに至ります。

回復処理におけるタイムアウトは下記の通り、複数のパラメータと計算式から決定されます。

 2 * ((LKPGSQL_CONN_RETRIES * 5) + (3 * LKPGSQL_STATUS_TIME) + (LKPGSQL_ACTION_RETRIES * 2))

参考情報:PostgreSQLリソースに関わる全てのパラメータがデフォルトの場合、回復処理のタイムアウトは292秒です。

1) 稼働状態の確認
 監視処理と同一の項目を確認し、PostgreSQLの稼働状態を確認します。

 本項目において起動状態にあると判断された場合、以降の回復操作は実施せずに回復処理は成功終了します。

 本項目において停止状態にあると判断された場合、以降の回復操作を実施します。

2) postgresプロセスの強制停止
 全てのpostgresプロセスに対するSIGTERM(15)を発行します。

3) PostgreSQLの停止
 停止処理の項目2)と同一の処理にて停止処理を実施します。

4) PostgreSQLの起動
 起動処理の項目2)と同一の処理にて起動処理を実施します。

 本項目において起動処理に成功した場合、回復処理は成功となります。

 本項目において起動処理に失敗した場合、回復処理は失敗としてフェイルオーバに至ります。

関連パラメータ
下記テクニカルドキュメントにおいて、PostgreSQL Recovery Kit のパラメータ名とその意味を説明しています。

PostgreSQLパラメータ一覧

関連資料
[Linux]PostgreSQL ARKにおけるpostgresql.confの”listen_addresses”の設定による起動オプションの違いについて
http://lk.sios.com/?p=3158

[Linux] Postgres Plus Advanced Server 8.3(Enterprise DB)を保護するには
http://lk.sios.com/?p=1508


改訂履歴

[公開日:2016年08月19日]

return top