PostgreSQLにおける時点復旧（Point-In-Time Recovery、PITR）

PostgreSQL

ポイントインタイムリカバリ（PITR）は、PostgreSQLにおける強力な機能であり、PostgreSQLの登場に伴い、さらに効率的でユーザーフレンドリーになりました。これにより、管理者はPostgreSQLデータベースを過去の特定の瞬間に復元することができます。これは、大規模なトランザクション負荷を持つ大規模システムの災害復旧を管理する際に特に便利です。

このブログでは、PITRを探求し、潜在的な落とし穴とその解決策に関する知識を提供し、スムーズで成功裏な実装を確実にします。また、その主な利点を共有し、PostgreSQLの段階的な実装を詳述します。

主なコンポーネント

PITRを実装するには、2つの主要なコンポーネントが必要です：

1. ベースバックアップ

ベースバックアップは、特定の時点でのデータベースのスナップショットです。データベースを元の状態に復元するために必要なすべてのデータファイル、設定ファイル、およびメタデータが含まれています。ベースバックアップは、PITRの出発点となります。

2. ウォールログ（WAL）

WALファイルは、データベースに加えられたすべての変更を記録します。これらのログは、特定の時点での状態にデータベースを復元するために必要な変更を保存します。PITRを実行する際には、WALファイルを順次再生して、希望するデータベースの状態を再現します。

PITRを使用する理由は？

PITRは、いくつかのシナリオで有益です：

誤って変更を取り消す

偶発的な操作、例えばDELETEやDROP文をWHERE句なしで実行すると、重大なデータ損失が発生する可能性があります。PITRを使用すると、間違いの直前の状態にデータベースを復元でき、重要なデータを保護します。

データ破損からの回復

アプリケーションバグ、ハードウェアの故障、またはディスクの破損はデータの不整合を引き起こす可能性があります。PITRを使用すると、クリーンなデータベーススナップショットを復元し、有効な変更のみを再生することができ、ダウンタイムとデータ損失を最小限に抑えます。

テストやデバッグのための復元

開発者は、デバッグやテストの目的で本番データベースを複製する必要がよくあります。PITRは、特定の時点でのデータベースのスナップショットを作成できるため、ライブデータに影響を与えることなく、制御された実験を行うことができます。

ディザスターリカバリー

PITRは、ディザスターリカバリーストラテジーに不可欠です。自然災害やサイバー攻撃などの重大な障害が発生した場合、データベースを最後の整合性のある状態に迅速に復元でき、ビジネスの継続性を確保します。

リソースの効率的な使用

定期的なベースバックアップとWALファイルを組み合わせることで、PITRは頻繁なフルバックアップの必要性を最小限に抑え、ストレージスペースを節約し、バックアップ時間を短縮します。PITRは特定の秒数までリカバリーすることができる正確なリカバリーメソッドでもあり、インシデント中のデータ損失のリスクを最小限に抑えることができます。単一トランザクションのロールバックから完全なデータベースの復元まで、さまざまなリカバリーシナリオを効率的に処理する柔軟性があります。

PostgreSQL 17のPITRでの新機能は？

PostgreSQL 17では、PITR向けにいくつかの強化が導入されており、パフォーマンス、使いやすさ、互換性に焦点を当てています。

フェイルオーバースロット同期

論理レプリケーションスロットは、フェイルオーバー中に同期をサポートするようになりました。これにより、PITRに必要なWALがフェイルオーバー後も保持され、手動介入が削減されます。

強化されたWAL圧縮

WAL圧縮アルゴリズムが更新され、ストレージ効率が向上し、WALのアーカイブに必要なスペースが削減されました。これは、高トランザクションレートを持つ大規模システムに特に有益です。

高速リカバリースピード

WALリプレイプロセスの最適化により、特に大規模データセットに対する回復時間が短縮されます。

論理レプリケーションとの互換性の向上

PITRは、物理的および論理的レプリケーションを活用するクラスターの回復を容易にするように、論理レプリケーションセットアップとの統合が改善されました。

詳細なWALアーカイブ管理

PostgreSQL 17は、WALアーカイブの管理をより提供し、回復要件に合わせて保持ポリシーを微調整できるようにします。

PostgreSQLでPITRを実行するための詳細な手順

PITRを設定して実行するために、次の手順に従ってください。PITRを使用する前に、次のものが必要です：

WALアーカイブ：WALアーカイブを有効にし、設定します。
ベースバックアップ：pg_basebackupまたはpgBackRestを使用して完全なベースバックアップを取得します。
安全なストレージ：バックアップとWALファイルが安全に保存されていることを確認します。できればオフサイトで。

1. WALアーカイブの設定

WALアーカイブは、バックアップ間の増分変更を保存するため、PITRには重要です。WALアーカイブを設定するには、postgresql.confファイルを更新し、次のように設定します：

Shell

wal_level = replica          # Ensures sufficient logging for recovery

​

archive_mode = on            # Enables WAL archiving

​

archive_command = 'cp %p /path/to/wal_archive/%f'  # Command to archive WALs

​

max_wal_senders = 3          # Allows replication and archiving

次に、設定パラメータを設定した後、PostgreSQLサーバーを再起動します：

Shell

sudo systemctl restart postgresql

次のコマンドでWALアーカイブのステータスを確認します：

SQL

SELECT * FROM pg_stat_archiver;

pg_stat_archiver ビューまたは PostgreSQL ログにエラーがないか確認します。

2. ベースバックアップを実行する

PITR の出発点として使用するベースバックアップを取得します。pg_basebackup を使用し、コマンドは次の形式になります：

Shell

pg_basebackup -D /path/to/backup_directory -Fp -Xs -P

これにより、一貫したデータベーススナップショットが作成され、リカバリのために WAL ファイルがアーカイブされることが保証されます。

3. バックアップの整合性を検証する

pg_verifybackup を使用してバックアップの整合性を検証します：

Shell

pg_verifybackup /path/to/backup_directory

4. 障害をシミュレーションする

デモンストレーション目的で、障害をシミュレートできます。たとえば、誤ってデータを削除する：

Shell

DELETE FROM critical_table WHERE id = 123;

5. ベースバックアップを復元する

ベースバックアップを復元する前に、PostgreSQL サーバーを停止します：

Shell

sudo systemctl stop postgresql

次に、既存のデータディレクトリの名前を変更するために次のコマンドを使用します：

Shell

mv /var/lib/pgsql/17/data /var/lib/pgsql/17/data_old

次に、データディレクトリをベースバックアップと置き換えます：

Shell

cp -r /path/to/backup_directory /var/lib/pgsql/17/data

データディレクトリの権限を更新します：

Shell

chown -R postgres:postgres /var/lib/pgsql/17/data

6. リカバリを設定する

リカバリモードを有効にするには、最初に PostgreSQL データディレクトリに recovery.signal ファイルを作成する必要があります：

Shell

touch /var/lib/pgsql/17/data/recovery.signal

次に、postgresql.conf を更新し、次のパラメータを追加します：

Shell

restore_command = 'cp /path/to/wal_archive/%f "%p"'  # Restore archived WALs

​

recovery_target_time = '2024-11-19 12:00:00'    # Specify target time

​

Alternatively, use recovery_target_lsn or recovery_target_name for more advanced scenarios.

7. リカバリモードで PostgreSQL を起動する

コマンドを使用して PostgreSQL サーバーを再起動します：

Shell

sudo systemctl start postgresql

リカバリの進捗をログで監視します：

Shell

tail -f /var/lib/pgsql/17/pg_log/postgresql.log

PostgreSQLは、リカバリが完了すると自動的にリカバリモードを終了し、運用モードに移行します。

8. リカバリの確認

リカバリ後、データベースの状態を検証してください：

SQL

SELECT * FROM critical_table WHERE id = 123;

問題の解決

欠落または破損したWALファイル

問題

リカバリに必要なWALファイルが欠落または破損しています。

解決策

バックアップとWALアーカイブを定期的にpg_verifybackupなどのツールを使用して検証してください。
WALアーカイブに冗長なストレージを使用してください。

不正確なリカバリターゲット

問題

リカバリが意図しない状態で停止します。

解決策

recovery_target_time、recovery_target_lsn、またはrecovery_target_nameを再確認してください。
pg_waldumpを使用して、WALファイルを対象イベントのために検査してください。

リカバリ中のパフォーマンスボトルネック

問題

大きなWALファイルにより、リカバリに時間がかかりすぎます。

解決策

maintenance_work_memおよびmax_parallel_workersを増やすことでリカバリのパフォーマンスを最適化してください。
ファイルサイズを縮小するためにWAL圧縮を使用してください。

クロックのズレの問題

問題

クロックの違いにより、リカバリのタイムスタンプを整合させる必要があります。

解決策

NTPなどのツールを使用してサーバークロックを同期してください。

誤ったWALアーカイブの設定

問題

不適切な archive_command により、WAL アーカイブの失敗が発生します。

解決策

archive_command を手動でテストします: cp /path/to/test_wal /path/to/wal_archive/。
アーカイブディレクトリに十分な権限があることを確認してください。

PITR のベストプラクティス

バックアップを自動化: pgBackRest や Barman などのツールを使用して、スケジュールされたバックアップと WAL アーカイブを行います。
WAL アーカイブを監視: 定期的に pg_stat_archiver を確認し、問題を特定します。
バックアップを検証: 常に pg_verifybackup を使用してバックアップの整合性を確認します。
リカバリ手順をテスト: 定期的にリカバリシナリオをシミュレーションし、準備を整えます。
WAL アーカイブを保護: WAL アーカイブには、クラウドサービスや RAID 構成のディスクなど、安全で冗長なストレージを使用します。

結論

ポイントインタイムリカバリ (PITR) は、データベースの信頼性を維持し、インシデント発生時のデータ損失を軽減するために重要です。pgEdge と PostgreSQL 17 の強化により、PITR はより迅速で効率的、かつ管理が容易になり、特に大規模または高可用性システムにおいてその効果を発揮します。

このガイドの手順とベストプラクティスに従うことで、PostgreSQL 環境で PITR を効果的に実装および管理することができます。定期的なテストと監視は、必要なときにリカバリプロセスが利用可能であることを保証するために不可欠です。

Source:
https://dzone.com/articles/point-in-time-recovery-pitr-in-postgresql