🌟

Aurora PostgreSQL のバックアップとリストアについて

2024/05/20に公開

AWS

はじめに

あらためて Aurora PostgreSQL のバックアップとリストアについて調べる機会があったので、ざっくりだがこちらにまとめておく。

以下のページを参考にさせていただいた。

https://iret.media/84351

前提条件

今回の調査では、長期間のデータ保持は不要で30日程度あればよい。
また利用シーンとしては、大規模なデータのリストアを想定。

方法

バックトラック

DB クラスターを特定の時点に巻き戻すことができる。
新しい DB クラスターを作成せずに DB クラスターを巻き戻すことができるため迅速にリストアができる。ただし、Aurora MySQLのみ利用可能。

バックトラックの注意点としては、稼働中の DB クラスターに対して操作を行うため稼働中のアプリケーションをメンテナンスモードにするなど対策を行い、データの不整合が発生しないような工夫が必要なところ。

ポイントインタイムリカバリ (PITR)

データベースの特定の時点 (最近の5分間以内) の状態に戻すことができる。
自動バックアップが有効な限り Aurora は自動バックアップを行う。自動バックアップは無効にすることができないためデフォルトでこの挙動となる。また、AWS Backupと合わせて利用可能。

PITR の注意点としては、DB クラスタごとバックアップするためリストア時には新しい DB クラスターが作成される。そのためコストは増える。また、自動バックアップの保持期間は最大で35日のため、それ以上の期間は指定できない。

スナップショット

基本的には手動実行のため、自動化するためには AWS Backup と組み合わせて使う。
35日以上の長期間のバックアップが可能。

スナップショットの注意点としては、AWS Backup の追加コストが発生するため、バックアップの量と期間には注意が必要。また、PITRと異なり増分バックアップではないたバックアップの作成やリストアに時間がかかる可能性がある。

リストア

ポイントインタイムリカバリ (PITR) + AWS Backup の合せ技で試してみた。
ざっくりとしたリストアの流れは以下の通り。

アプリケーションをメンテナンスモードにする
通常リストアが必要なケースの場合は、緊急性が高くアプリケーションに致命的な問題が発生しているなどの場合が多いためメンテナンスモードにするのがベター
AWS Backupのバックアップボールドから、復旧ポイントを選び復元したい日時と時刻を指定して、復元する
しばらくすると、既存の DB クラスターとは別名でリストアされる

writerインスタンスは AWS マネージメントコンソールから追加できないため以下のコマンドで追加する

# Aurora PostgreSQL Serverless v2の場合
$ aws rds create-db-instance \
--db-instance-identifier xxxxx \
--db-cluster-identifier yyyyy \
--engine aurora-postgresql \
--db-instance-class db.serverless

readerインスタンスを AWS マネージメントコンソールから追加する
必要に応じて既存の DB クラスターとリストアした DB クラスターのダンプを取り、差分がないことを確認する
アプリケーションの DB 接続先をリストアした DB クラスターへ向け再起動など行う
アプリケーションの動作確認を行う
アプリケーションのメンテナンスモードを解除する

気になった点

アプリケーションのダウンタイムが長い
スナップショットを取る方法と比べるとストレージコストが高め？
リストア後に CDK でリソース管理するのが難しい
- fromDatabaseClusterAttributes メソッドを使用して参照するかたちとなるので以降、このリソースに対する操作を CDK 空行うことが難しい

結論

利用シーンとしては、大規模なデータのリストアを想定していたため、
ポイントインタイムリカバリ (PITR) + AWS Backup の方法を採用した。

リストア後に CDK 管理が難しいという課題はあったが、緊急時にはまずアプリケーションの復旧を優先させるべきと判断した。ここについては別途検討したい。