• 検索結果がありません。

その他の障害

ドキュメント内 PostgreSQL Internals (1) (ページ 143-148)

4. 障害対応

4.4 その他の障害

4.4.1 クラッシュ・リカバリ

インスタンスが異常終了した場合、チェックポイントが完了していないため実行した更 新トランザクションの情報はWAL のみに書き込まれています。インスタンス起動時には、

データファイルとWALの不整合を調整するクラッシュ・リカバリ処理が自動的に行われま す。

クラッシュ・リカバリはpg_controlファイルの読み込みからはじまります。インスタン スのステータスが DB_SHUTDOWNED (1) の場合、インスタンスは正常に終了している ためクラッシュ・リカバリは行われません。それ以外のステータスの場合、インスタンスは 異常終了したことになるためクラッシュ・リカバリが必要になります。

以下に処理を簡単に示します。

1. チェックポイントの位置を確認。チェックポイントまでの WAL はデータファイル に書きこまれたことが保障されているため、リカバリーの必要がありません。

2. WALから前回のチェックポイント後に発生したトランザクション情報を読み込み 3. チェックポイント後の最初の更新ではブロック全体が WAL に書き込まれているた

め、ブロックをリカバリー(パラメーターfull_page_writes)

4. WAL情報から更新トランザクションの情報を適用 5. 最新のWALまで更新トランザクションを再実行

4.4.2 オンライン・バックアップ中のインスタンス異常終了

PostgreSQLのオンライン・バックアップは以下の手順で実施します。

1. インスタンスをアーカイブログ・モードで起動 2. pg_start_backup関数の実行

3. データベース・クラスターのファイルをコピー(OSコマンドによる)

4. pg_stop_backup関数の実行

上記手順のうち、3の実行中にインスタンスが異常終了した場合の動作を検証しました。停

止はpostmasterに対してKILLシグナルを送信することで行いました。

例 123 オンライン・バックアップ中のインスタンス異常終了

postmaster.pidファイルが削除されていないため、警告が出力されていますが、再起動は

正常に行われました。またpg_stop_backup関数を実行したところバックアップ中ではない というエラーが返っていることからバックアップ・モードはインスタンスの再起動によっ てクリアされることがわかります。

4.4.3 アーカイブ処理の失敗

WAL ファイルが完全に書き込まれると、パラメーターarchive_command に指定された

コ マ ン ド が system 関 数 (Linux / Windows 共 ) を 使 っ て 実 行 さ れ ま す

(src/backend/postmaster/pgarch.c内のpgarch_archiveXlog関数)。

□ アーカイブ処理の再実行

system関数が0以外の値を返すと、アーカイブ処理が失敗したとみなされ、3回リトラ

イを実行します。3回のリトライをすべて失敗すると最大で60秒待機します。

postgres=# SELECT pg_start_backup('label') ; pg_start_backup

--- 0/5000020

(1 row)

$ ps -ef | grep postgres

postgres 6016 1 0 12:46 pts/1 00:00:00 /usr/local/pgsql/bin/postgres

$ kill -KILL 6016

$ pg_ctl -D data start -w

pg_ctl: another server might be running; trying to start server anyway server starting

postgres=# SELECT pg_stop_backup() ; ERROR: a backup is not in progress

図 14 アーカイブ処理の再実行

アーカイブ処理の失敗回数等は、pg_stat_archiver カタログで確認することができます

(PostgreSQL 9.4から)。

□ アーカイブ処理の失敗ログ

アーカイブ処理が失敗すると、ログが出力されます。下記の例は、パラメーター

archive_commandに「cp %p /arch/%f」を指定し、アーカイブログ出力ディレクトリに書

き込み権限が無い場合のエラーです。cpコマンドがステータス1で終了しています。

3回LOGレベルのエラーが続き、最後にWARNINGレベルのエラーが出力されていま す。

最大60秒待機 回数無期限

1秒待機 最大3回

例 124 アーカイブ処理失敗のログ

アーカイブ処理失敗時に出力されるエラー・メッセージは以下の通りです。

表 53 アーカイブ処理失敗ログ

レベル メッセージ 説明

WARNING archive_mode enabled, yet archive_command is not set

アーカイブログ・モードだが、パラメ ーターarchive_commandが未設定 WARNING archiving transaction log file

¥”%s¥” failed too many times, will try again later

3 回のリトライがすべて失敗したた め、一時的に待機する

FATAL | LOG

archive command failed with exit code %d

アーカイブ・コマンドが失敗ステー タスで終了

FATAL archive command was terminated by exception

アーカイブ・コマンドが例外を受け て失敗(Windows)

FATAL archive command was terminated by signal %d

アーカイブ・コマンドが例外を受け て失敗(Windows以外)

FATAL | LOG

archive command exited with unrecognized status %d

アーカイブ・コマンドが不明なエラ ーで終了

cp: accessing `/arch/000000010000000000000070': Permission denied LOG: archive command failed with exit code 1

DETAIL: The failed archive command was: cp pg_xlog/000000010000000000000070 /arch/000000010000000000000070

cp: accessing `/arch/000000010000000000000070': Permission denied LOG: archive command failed with exit code 1

DETAIL: The failed archive command was: cp pg_xlog/000000010000000000000070 /arch/000000010000000000000070

cp: accessing `/arch/000000010000000000000070': Permission denied LOG: archive command failed with exit code 1

DETAIL: The failed archive command was: cp pg_xlog/000000010000000000000070 /arch/000000010000000000000070

WARNING: archiving transaction log file "000000010000000000000070" failed too many times, will try again later

エラー・レベルの選択(FATALまたはLOG)は、WEXITSTATUSマクロが128を超え る場合またはWIFSIGNALEDマクロが真になる場合はFATAL、それ以外はLOGになり ます。

□ アーカイブ失敗時のWAL

アーカイブ処理が失敗すると、処理が失敗したWALファイルは再利用されず新規のWAL ファイルが追加されます。このためアーカイブ処理が失敗し続けると、pg_xlogディレクト リ以下に大量のWALファイルが残ることになります。

ドキュメント内 PostgreSQL Internals (1) (ページ 143-148)