STEP 1. DBスナップショットでバックアップを作っておく

( 自動バックアップから復元したり「特定時点への復元」をする場合はこの手順は不要 )

STEP2. 復元する

AWS RDS の仕組みとして、復元操作をしても元となったDBの状態が上書きされるわけではなく、いったん別のDBクラスタが作成される。

このため、この復元操作以外にも作業が必要だが、それは次の STEP 3で説明する。

元のスナップショットから全ての設定を復元してくれるわけではなく

など、選び直さなければばいけないものもあるので、注意して適切なものを選び直す

既存DBクラスタ・インスタンスの設定と見比べてから復元した方が良いかもしれない

何らかの形で、アプリケーションが復旧後のDBに紐付くエンドポイントを参照するようにする。

DB復元後に生成されたクラスタ、インスタンス、DBエンドポイントをそのままアプリケーションから利用する方法。

この方法ではDB切断が発生しない。

まずはアプリケーションが接続するDBエンドポイントを、復元後のDBのものに差し替える。

たとえば

のように変更する。

アプリケーションの構成やデプロイの仕組みにもよるかもしれないが、この場合はアプリケーションの再デプロイ / 再起動などが必要なはずだ。なので必要があればアプリケーションの再デプロイ / 再起動をする。

ただし Terraform で AWS構築をしている場合など、RDS設定とインフラコードに差分が生じてしまう場合は、インフラコードでもつじつまを合わせるための調整が必要になる。

AWS RDS でDBの「クラスタ識別子」(またはインスタンス識別子)の命名を付け直すことで、DBに紐づくエンドポイントも入れ替えることが出来て、正しい状態に戻せる。

「アプリケーションの接続先のDBエンドポイントのパス」自体は変えずに、DBエンドポイント対 DB の対応を変える方法。

ただしこの場合、DBクラスタ識別子を変更している最中には「アプリケーションからの接続先のDBエンドポイントが存在しない時間」が発生してしまい、DBの切断が発生する。

たとえば RDSの DB クラスター識別子が次の命名だった場合

次のように名前をつけ直せば、

DBエンドポイントもそれぞれ以下のように変わる

すなわち、以前から利用していたDBエンドポイントのパス自体は変えずに、DBを復元後の状態に入れ替えることができる

この方法ではアプリケーションの再デプロイは必要ない

アプリケーションが「インスタンス識別子を使ったDBエンドポイント」を利用している場合は、インスタンス識別子の方を変更する必要がある

何か質問、悩み事、相談などあればLINEオープンチャットもご利用ください。