PricingLoginStart free
Advanced PostgreSQL: Indexing, Partitioning, Replication · レッスン

ディザスタリカバリ戦略

レプリケーション環境のバックアップおよびリストア手順を含む、包括的なディザスタリカバリ計画を策定します。

レッスン 3/412 ステップ

「ディザスタリカバリ戦略」はCoddyKit上の無料Advanced PostgreSQL: Indexing, Partitioning, Replicationレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。 これはAdvanced PostgreSQL: Indexing, Partitioning, Replication学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 Advanced PostgreSQL: Indexing, Partitioning, Replicationコースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

DR for Replicated PostgreSQL

Even with high availability (HA) setups like replication, unexpected disasters can strike. Think data center outages, major corruption, or human error.

Disaster Recovery (DR) is your plan B. It's about recovering your database system after a catastrophic event to minimize data loss and downtime.

DR vs. HA: What's the Difference?

It's easy to confuse High Availability (HA) with Disaster Recovery (DR), but they serve different purposes:

  • HA: Aims to keep systems running with minimal interruption during minor failures (e.g., a single server crash, network glitch). It often involves automatic failover to a standby.
  • DR: Focuses on recovering from major, widespread failures that take down an entire region or multiple components, where HA alone might not suffice.

Replication is a cornerstone for both, but DR requires additional planning for recovery.

Essential DR Plan Elements

A robust Disaster Recovery plan for PostgreSQL involves several key components:

  • Regular Backups: Both full base backups and continuous Write-Ahead Log (WAL) archiving.
  • Recovery Objectives: Defining your RTO (Recovery Time Objective) and RPO (Recovery Point Objective).
  • Offsite Storage: Storing backups safely away from your primary data center.
  • Tested Procedures: Documented and regularly practiced restore processes.

RTO & RPO: Your Recovery Goals

These two metrics are crucial for any DR plan:

  • Recovery Time Objective (RTO): This is the maximum acceptable duration of time that a computer system, application, or network can be down after a disaster. It's about time to recover.
  • Recovery Point Objective (RPO): This is the maximum acceptable amount of data loss measured in time. For example, an RPO of 1 hour means you can lose up to 1 hour of data. It's about data loss tolerance.

Your RTO and RPO will dictate your backup frequency and recovery strategy.

Backup Types for DR

For replicated environments, you typically combine two types of backups:

  • Base Backup: A full snapshot of your database cluster at a specific point in time. This forms the foundation for any restoration.
  • WAL Archiving: Continuously saving the Write-Ahead Log (WAL) files. These logs record all changes to your database and are essential for point-in-time recovery and keeping standbys up-to-date.

Together, they enable restoring to any point within your archived history.

Creating a Base Backup

pg_basebackup is the go-to tool for creating a base backup. It can even take a backup from a running standby server to offload work from the primary!

This command creates a full copy of the data directory. The -X stream or -X fetch options are often used to include WAL files, making the backup self-contained.

Try this example:

pg_basebackup -h localhost -p 5432 \
  -U backup_user -D /path/to/backup/dir \
  -Ft -Xs -P -R

Setting up WAL Archiving

WAL archiving is critical for point-in-time recovery and ensuring your standbys can catch up even if the primary crashes. It involves copying completed WAL files to a safe, often remote, location.

You configure this in your postgresql.conf file:

archive_mode = on
archive_command = 'cp %p /path/to/wal_archive/%f'
max_wal_senders = 10
wal_level = replica

Restoring a Failed Primary

If your primary server fails catastrophically, you'll need to restore it. This typically involves:

  1. Initializing a new data directory.
  2. Restoring the latest base backup into the new directory.
  3. Configuring a recovery.signal file (or standby.signal for older versions) and postgresql.conf to point to your WAL archive.
  4. Starting PostgreSQL, which will then replay the WAL files to bring the database to the desired point in time.

This process can also be used to create a new primary from a standby backup.

Rebuilding a Standby

After a disaster, you might also need to rebuild your standby servers to connect to the newly restored (or promoted) primary. The process is similar to setting up a new standby:

  1. Take a fresh base backup from the new primary.
  2. Configure the standby's postgresql.conf and standby.signal to connect to the new primary.
  3. Start the standby. It will then stream WAL from the new primary to synchronize.

This ensures your replication chain is healthy again.

Test, Test, and Test Again!

A DR plan is only as good as its last test. Regularly practicing your recovery procedures is vital. This helps you:

  • Identify gaps or errors in your documentation.
  • Ensure your recovery time (RTO) is achievable.
  • Train your team on the recovery process.
  • Confirm backups are valid and restorable.

Schedule regular DR drills, perhaps annually or semi-annually, in a non-production environment.

DR Scenario Check

Imagine a major data center outage has taken down your primary PostgreSQL server and all its local standbys. You have offsite base backups and continuous WAL archiving.

Which of the following describes the maximum acceptable amount of data loss you are willing to tolerate in this scenario?

対話的なレッスンで答える

Disaster Recovery Recap

We've covered the essentials of Disaster Recovery for PostgreSQL in replicated environments. Remember these key takeaways:

  • DR protects against catastrophic failures, complementing High Availability.
  • Define RTO (time to recover) and RPO (data loss tolerance) for your systems.
  • Combine base backups and WAL archiving for comprehensive recovery.
  • pg_basebackup and archive_command are crucial tools.
  • Always test your DR plan regularly to ensure readiness.

A well-practiced DR plan is your safety net for critical data.

無料で開始

AI チューターと学ぶ Advanced PostgreSQL: Indexing, Partitioning, Replication — 無料

ブラウザでリアルコードを書いて実行し、24/7 の AI チューターから瞬時にサポートを受け、ウェブまたはアプリで続きから学習できます。

コース
11
レッスン
44
無料で学習を始めるコース全体を表示

よくある質問

「ディザスタリカバリ戦略」レッスンは無料ですか？

はい。「ディザスタリカバリ戦略」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、Advanced PostgreSQL: Indexing, Partitioning, Replicationコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 Advanced PostgreSQL: Indexing, Partitioning, Replicationコースには全4レッスンが含まれています。

「ディザスタリカバリ戦略」で何を学びますか？

レプリケーション環境のバックアップおよびリストア手順を含む、包括的なディザスタリカバリ計画を策定します。 ブラウザで直接実行するハンズオンコードでAdvanced PostgreSQL: Indexing, Partitioning, Replicationを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

Advanced PostgreSQL: Indexing, Partitioning, Replicationを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAdvanced PostgreSQL: Indexing, Partitioning, Replicationは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。

「ディザスタリカバリ戦略」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAdvanced PostgreSQL: Indexing, Partitioning, Replicationレッスンでコードを書いて実行できますか？

はい。すべてのAdvanced PostgreSQL: Indexing, Partitioning, Replicationレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

  1. 自動フェイルオーバーツール（Patroni）
  2. レプリケーションの健全性監視
  3. ディザスタリカバリ戦略
  4. PgBouncerとHAProxyによる接続ルーティング
← Advanced PostgreSQL: Indexing, Partitioning, Replicationに戻る