はじめに
RDBを使った新規案件が発生し、バッチ運用がメインとなってくるシステムだった為、
スモールスタートで運用するにはコストが安く、スケールしやすいと言う事で
Amazon Aurora(Postgres)を使うことになった。
自動でバックアップをしてくれる事から、復元も安易に出来るような雰囲気があったが
実際の所はどうなのか、調査した。
2種類の復元方法
復元方法は2種あり、いずれの復元の方法もデフォルトで7日間、最大35日分のデータを保存できる
スナップショットによる復元
スナップショット一覧から選択して復元が可能で、
バックアップは一日1回、自動で実施している特定時点への復元
コンソール右上の「アクション」から「特定時点への復元」を選択すると実行でき、
こちらは任意の時点のデータへ復元することが出来る。
リレーションの担保
「特定時点への復元」ではDB間整合性が担保出来ないと書いてある。
(つまり復元前後でアクセスがあるとリレーションが崩れる可能性がある)スナップショットにはその旨の記載が無かった
(現状、システムを動かしていないタイミングで丁度スナップショットが実施されており、
コールドバックアップされているかは確認が取れなかった)
障害発生 → 復元を実行して後は放置 とはならない
これが重要なのですが、今稼働している復元元のDB識別子は復元先に選べません
(考えてみればそれはそうだとなった箇所ですが、
当初出来るものと思い込んで居たのでこの記事を書いてます)
(Auroraの復元画面。DBクラスター識別子を同じにしても実行時エラーが出る)
つまり...
↑ こういう事が出来ない。
恐らく稼働中のDBを誤ってデータを消さないようにする措置だと思います。
こういう事態は避けるべきですね
今回検討した案
今回は案を2つ出し、その中の案2を採用しました。
-
案1 : 新しく本番DBを作る
- 復元したDBを新本番DBとし、復元元と全く同じ設定に仕上げ、DB接続先設定を新本番DBに向ける
- 慣れれば問題無いのだろうが、障害発生の際に設定項目を精査するのは難がある
- DB識別子も変わる
- 既に大量にデータを持っている場合には後述する手順に比べれば復元手順に掛けるコストは少ない
-
案2 : 復元用のDBを作り、postgresのダンプ機能から復元を実施する
- 復元したDBをリカバリー用DBとし、PostgresコマンドにてDBバックアップを取得、それを本番機へリストアする
- 手を加える本番システムがDBのみなのでミスの積み重ねが起きにくい
- 手順が一定化しやすい
- PostgresによるDB吸出しを行う為時間が掛かる、リカバリー中はデータも膨れる
参考URL：
- https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html
- https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/USER_PIT.html