[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コマンドを通じた起動および起動状態の確認（その１）
本項目は PostgreSQL が起動状態と判定されるまで、最大で LKPGSQL_ACTION_RETRIES に指定された回数まで繰り返します。

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

・パラメータ筆頭がIPアドレス

# su - <initdb 実行時のユーザ> -c pg_ctl -D <DataDir> -o “-k <SocketDir> -p <Port>” -l <logfile> start

※<initdb 実行時のユーザ>: 通常は postgres ユーザです。（以降も同じ）

・パラメータ筆頭がホスト名

# su – <initdb 実行時のユーザ> -c pg_ctl -D <DataDir> -o “-i -k <SocketDir> -p <Port>” -l <logfile> start

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

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

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

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

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

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

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

# su – <initdb 実行時のユーザ> -c “sh -c LANG=C pg_ctl -D <DataDir> status”

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

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

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

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

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

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

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

# su – <initdb 実行時のユーザ> -c “sh -c LANG=C pg_ctl -D <DataDir> 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 – <initdb 実行時のユーザ> -c pg_ctl -m fast -D <DataDir> -o “-k <SocketDir> -p <Port>” -l <Logfile> stop

・LKPGSQL_SDIRS へ指定されたデータディレクトリ

 # su – <initdb 実行時のユーザ> -c pg_ctl -m smart -D <DataDir> -o “-k <SocketDir> -p <Port>” -l <Logfile> stop

・LKPGSQL_IDIRS へ指定されたデータディレクトリ

# su – <initdb 実行時のユーザ> -o pg_ctl -m immediate -D <DataDir> -o “-k <SocketDir> -p <Port>” -l <Logfile> 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 – <initdb 実行時のユーザ> -c pg_ctl -D <データディレクトリ> status

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

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

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

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

1-2) プロセスIDの確認
a) netstat コマンドの出力から postmaste rプロセスの 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 <dbユーザ> -c \dS -d template1</dbユーザ>

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

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

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

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

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

# su – <initdb 実行時のユーザ> -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)

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

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

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”の設定による起動オプションの違いについて
https://lkdkuserportal.sios.jp/hc/ja/articles/360037730091

[Linux] Postgres Plus Advanced Server 8.3(Enterprise DB)を保護するには
https://lkdkuserportal.sios.jp/hc/ja/articles/360037734551 

改訂履歴

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

[改訂日：2020年04月14日]（体裁修正）

[改訂日：2020年08月05日] コマンドラインを postgres ユーザ以外も対象とした内容に修正。

 

関連記事