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

②③ ログ適用

障害とリカバリのシナリオ

„データベースクラスタ（テーブルスペース）領域のロスト

y

データベースクラスタ（またはテーブルスペース）領域を失った場合には、ベースバック アップからデータベースクラスタをレストアし、アーカイブログを用いてリカバリをする必 要があります。

y

オンラインWALファイルが残っている場合には「完全リカバリ」が可能です。

„ オンラインWAL領域のロスト

y

オンラインWALを失うと、PITRによるリカバリは「不完全リカバリ」となります。完全リカ バリはできません。

y

PostgreSQLが起動しなくなる可能性が高いため、ベースバックアップ＋アーカイブ WALからリカバリを実施（不完全リカバリ）。

„ アーカイブWAL領域のロスト

y

アーカイブWAL領域の障害は、サービスにはすぐには影響しません。

y

但し、アーカイブできなくなると、（再利用できなくなるため）オンラインWAL領域を圧迫 し始めるため、アーカイブを再開できるよう、アーカイブWAL領域を復旧させる必要が あります。

y

また、障害が発生した際には、アーカイブWALがないとリカバリできないため、再度、

ベースバックアップを取得する必要があります。

リストア、リカバリ手順

„ PostgreSQLサーバを停止する

„ 障害の発生したデータベースを保存する（可能であれば）

y

データベースクラスタ

y

トランザクションログ（残っている場合は必ず保護する）

y

テーブルスペース

„ ベースバックアップをレストアする

„ベースバックアップ取得以降のアーカイブログをレストアする

„ 最新のトランザクションログを配置する

„ リカバリ設定ファイル（recovery.conf）を作成する

„ PostgreSQLサーバを起動し、リカバリ処理を実行する

„ 実施したリカバリを一意に識別するための時間軸

y

PITRによるリカバリを行うと、完了した時点でタイムラインIDが繰り上がる

y

これによってアーカイブWALファイルが上書きされなくなる

„ PITRのリカバリはベースバックアップのタイムラインに沿って実施される

y

アーカイブWALファイルの途中でタイムラインが変更されていると、デフォルトではアー カイブWALの適用が行われない。

y

対策１：recovery.confでタイムラインを指定してリカバリを行う。

y

対策２：タイムラインが変わったら即時にベースバックアップを取得し直す。

タイムライン

Crash

TimelineID = 1

PITR

リカバリ実施

Timeline

更新

TimelineID = 2

今ダウンロードする "Microsoft PowerPoint -..."

Outline

関連したドキュメント