今日も例によってAWSシリーズですが、今回は恥ずかしながらRDSのリストア時に手こずってしまった内容を記事にしたいと思います。
目次
RDSとは
RDSはAmazon Web Servicesで提供されるリレーショナルデータベースサービスです。
簡単に言ってしまうとMySQLやらPostgreSQLやらをクラウド上でホスティングしてくれます。
なお今回はRDSのリストアについての記事ですので詳細については省略いたします。
RDSのリストア
私の失敗
一般的なサーバ上でMySQLやPostgreSQLを使っていると、一旦データベースを削除してダンプしたファイルをリストアするという場面が多くあります。
この感覚のままRDSを使って「一旦インスタンスを削除して今日の○○時に取得した自動スナップショットからインスタンスを復元」しようとしました。
RDS管理画面上での私の誤った操作
RDS管理画面でインスタンスの操作から削除を選択。
○○時の自動スナップショットがあればOKだから最終スナップショットは不要と思い、最終スナップショットを取得せずにインスタンス削除を実行しました。
インスタンス削除前後のスナップショット保持状態
インスタンス削除前のスナップショット保持状態。自動的に取得されたスナップショットが1つあります。
インスタンス削除後のスナップショット保持状態。
というわけで、綺麗さっぱり自動スナップショットが消えてしまいました。
よくよく考えてみれば当然の結果ですが、「自動スナップショット=ダンプファイル」ではなく、インスタンスと紐づいたスナップショットですので、インスタンス削除実行前には任意でスナップショットを取得するなどの対応が必要だと良くわかりました。
ちなみに任意で取得した手動スナップショットや削除時に聞かれた最終スナップショットは削除されませんでした。
手動や自動で取得したスナップショットがインスタンス削除時に消えるか消えないかは以下の通りです。
名称 | 概要 | インスタンス削除後 |
---|---|---|
自動スナップショット | 自動的に作成されるスナップショット | 消える |
手動スナップショット | 任意の時点で取得したスナップショット | 消えない |
最終スナップショット | インスタンス削除時に作成をきかれるスナップショット | 消えない |
自動スナップショットを使った正しいリストア方法
上記のリストアで問題なのは、当然ながらインスタンスを削除してしまったという点に尽きるのですが、自動バックアップ使った正しいリストア方法を行ってみたいと思います。
まず自動スナップショットから復元する
復元したい自動スナップショットを選択して「スナップショットの復元」を実行します。
既に使用しているインスタンス識別子(nediatest2)は利用できないので今回はnediatest3として復元しました。
復元完了後のインスタンス状態は以下の通りです。
エンドポイント名を変更する
このままnediatest3のエンドポイントを使用しても良いのですが、システムアプリケーション側で接続先エンドポイントの変更作業が必要になってしまいます。
これを防ぐためにインスタンス識別子を変更して対応します。
nediatest2をnediatest12へ変更
インスタンスの操作でnediatest2の変更をクリックします。
nediatest2をnediatest12へ変更します。
「すぐに適用」にチェックを入れて完了です。
ご覧のように再起動がいったんかかりますが、インスタンス識別子が変更されているのが分かります。
nediatest3をnediatest2へ変更
同様にnediatest3をnediatest2へ変更します。
完了
無事変更が完了しました。
これで元々のエンドポイント名で接続可能です。あとは動作確認ができればnediatest12は削除して良さそうです。
まとめ
というわけで無事RDSのリストアが完了しました。
当然のことをきちんと理解していれば今回の失敗は避けられただけに悔やまれます。失敗は成功の元なんて言いますが、今回の失敗で改めてデータの取り扱いには注意しようと思った千本木でした。
ちなみに誤って自動スナップショットを削除してしまったのは私のテスト用データベースでしたので実害はありませんでした。