今回はRDS（PostgreSQL）のバックアップとリストアについて解説していきます。
以前書いたAuroraのバックアップ記事と似ている部分が多く、合わせて読んで頂けるとさらに理解が深まるかと思います。
※本ページはプロモーションが含まれています。
バックアップ
RDSのバックアップはスナップショット（増分）として取得されます。
内部的にはEBSスナップショットになるため、以下のような特徴があります
- ストレージだけでなく、DBインスタンスまるごとバックアップされる。
- スナップショットを別リージョンへコピーしたり、別アカウントに共有したりすることができる。
また、スナップショットをS3にエクスポートすることも可能です。ただ、これはコスト節約が目的ではなく、Athenaなどを使ってデータ分析を行いたい時に活躍する機能になるかと思います。S3からインポートする場合は、DMSを使ったりする必要があります。
自動と手動のバックアップがあるのですが、まずは結論から。
それぞれ解説していきます。
自動バックアップ
自動バックアップを有効にすると、日次でスナップショットが取得されます。
また、5分毎にトランザクションログをS3にバックアップします。これはPITR（ポイントインタイムリカバリ）を行うのに必要です。
保持期間
保持期間は、「0~35日間」を指定することができます。
バックアップによるコストは、DBインスタンスのサイズと同じであれば無料です。
バックアップウィンドウ
指定したウィンドウ内でバックアップが行われます。
自動バックアップ開始時は、一時的にストレージIOが中断されることがあります(数秒)。これは、複数台構成にすると、スタンバイからバックアップを取得するようになり、プライマリでのIO断を避けることが可能です。
ただ、マルチAZ配置のバックアップ中はレイテンシーが高くなることもあるため、忙しく無い時間帯で指定することが望ましいです。
別リージョンへの自動バックアップのレプリケーション
災害対策として、スナップショットとトランザクションログを別リージョンにレプリケーションさせることができます。（リージョン障害対策目的など）
手動バックアップ
AWSコンソールやAWS Backupを利用して、手動でスナップショットを取得することが可能です。
自動バックアップとは打って変わって、保持期間以外に目立った点はありません。
保持期間
保持期間は無制限です。
リストア
スナップショットから新しいDBインスタンスを作成することでリストアすることができます（既存のDBに変更を加えるわけではないため注意）。
リストアした際は、ステータスがavailableになれば使用することが可能です。ただ、availableになっていても、バックグラウンドではS3からデータをダウンロードし続けている(遅延ロード)可能性があります。そのため、まだダウンロードされていないテーブルにアクセスすると、「データのダウンロード＋クエリの実行」となるので性能が落ちることがあります。すぐにアクセスが必要なテーブルには、 SELECT * を実行してウォームアップしておく必要があります（キャッシュにデータを乗せる意味でも）。
PITR(ポイントインタイムリカバリ)
DBを特定の時点に戻すことができます（最短で5分前）。これは、自動バックアップを有効にしておく必要があります。こちらも通常のリストアと同様に、新たにDBインスタンスを作成してリストアを行います。
Tips
レプリケーション遅延のチューニングについて
RDS（PostgreSQL）のレプリケーションは「ストリーミングレプリケーション」で通常行われています。
（参考）https://aws.amazon.com/jp/blogs/news/best-practices-for-amazon-rds-postgresql-replication/
ただ、レプリケーション遅延が発生する（ReplicaLagのメトリクスで確認が可能）と、スタンバイサーバはS3にバックアップされたトランザクションログを利用してデータを復元します。これはストリーミングレプリケーションに比べて時間が掛かるため、なるべく避けたいところ。そのためには、wal_keep_segmentsを増やして、DBをインスタンスで持てるトランザクションログ量を増やすことでチューニングすることが可能です。
コメント