107
91

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

RDSでDBをスナップショットから復元する

Posted at

こんにちはみなさん

サービスを更新するとき、ときには現時点でのデータベースのデータ構造に手を入れる必要が出てくるかもしれませんが、そんなときは必ずバックアップをとっておくものです。
随分前であれば、mysqldumpとかを使って生のダンプファイルを取っておいて、復旧時はそのダンプファイルを入れ直すというふうにやっていたと思うのですが、AWSのRDSではスナップショットを定期的に、もしくは能動的に取得することができ、このスナップショットからDBを復元するという手段があるので、それを頼りにする場合があるでしょう。

私の場合は、コンテナ運用時にはそもそもRDSへ直接アクセスする手段を封じていますので、スナップショットによる復元以外には (セキュリティグループの設定を変えたりしない限り) 方法がありません。

そんなわけで、RDSでスナップショットからDBを復元するときに、引っかかりそうになった部分を、実際のシナリオを元にしてピックアップしていきましょう。

シナリオ: DBに大きな変更が入る

メンテナンス作業

実際にDBに大きな変更を入れる場合、コンテナ運用でブルーグリーンデプロイができる状況であっても、データの動きが発生しないようメンテナンスを入れるべきでしょう。
今回は以下のような手順でメンテを実施したとします。

  1. アプリケーションをメンテIN
  2. RDSのスナップショットを取得する
  3. バッチでデータを改変する
  4. デプロイの成否判定をする
  5. 成功したらメンテOUT

まず、スナップショットはメンテに入ってからデータ改変するまでの間にとっておきます。
こうすることで、データ改変前の最新の状態を保存しておくことができます。
操作方法はマネジメントコンソールであれば、

RDS -> インスタンス -> (対象のインスタンスを選択) -> インスタンスの操作 -> スナップショットの取得

で実施できます。

snapshot.png

そして、デプロイの成否判定で、成功しなかった場合に、スナップショットからRDSを復元する作業が入ります。

復元作業

復元するときは次の手順に従います。

  1. メンテは継続
  2. 現在のRDSインスタンスの識別子を変更する(アプリケーションからのDB接続ができなくなる)
  3. スナップショットから復元する。復元時に元のインスタンスの識別子を指定する
  4. インスタンスが起動する
  5. インスタンスのパラメータグループとセキュリティグループを変更する(変更適用後、アプリケーションからの接続が可能になる)
  6. 復元したRDSを再起動する
  7. メンテOUT

意外と手順が多いですね。
もう少し簡単になってくれないかなぁって思いますが、こんなもんなんでしょう。
スナップショットから復元するためには以下のようにします。

RDS -> スナップショット -> (直前に保存したスナップショットを選択) -> スナップショットのアクション -> スナップショットの復元

restore.png

このあと、RDSインスタンスを生成するためのウィザードが立ち上がります。

注意点

スナップショットからの復元は、インスタンスを生成することである

これ知らなかったんですが、スナップショットからの復元って、既存のDBをロールバックするんじゃなくて、新しくインスタンスを立ち上げることなんですね。
なので、現行DBが残った状態で復旧DBを立ち上げることになります。

復元手順において、はじめに現行のDBの識別子を変更しているのは、復旧DBに現行のDBの識別子を付けさせることで、アプリケーションから接続できるようにするためです。
あとで変えればいいかもですが、この段階で変えておいたほうが早いんじゃないかと。

セキュリティグループとパラメータグループが初期化される

指定した時刻のソース DB インスタンスから新しい DB インスタンスを作成します。この新しい DB インスタンスにはデフォルトの DB セキュリティグループと DB パラメータグループが関連付けられます。 この機能は現在、 InnoDB ストレージエンジンでのみサポートされています . MyISAM テーブルを使用している場合、詳細については以下を参照してください こちら .

ここが面倒なところなのですが、復元されたインスタンスのセキュリティグループとパラメータグループは、何故か元のインスタンスのそれを引き継いでくれません。
つまり、一旦復元が完了してインスタンスが起動した状態で、あらためてセキュリティグループとパラメータグループを変更する必要があります。

パラメータグループは、日本語を含むデータを格納する場合はcharacter_setをutf8にしておく必要があるのですが、デフォルトを適用されてしまい、latin1とかいうクソみたいなcharacter_setになっているので、このままデータを格納してしまうと、文字コードがずれるというかなりまずい状態が発生するかもしれません。

さらに、パラメータグループの変更には再起動が必要なので、ダウンタイムが発生します。
なので、再起動が住んでからメンテを開けるようにする必要があります。

古いインスタンスも少しの間だけ残しておくべき

スナップショットからDBを復元した後、データ改変に失敗した古いインスタンスはさっさと消したいところですが、上述したように、いくつか完全に復元できていない部分が出てしまいます。
そのため、メンテ中の確認はメンテ明け後しばらくは古いインスタンスを残しておき、異常が発生した際に復元DBのパラメータに誤りがないかを確認するようにした方がいいです。

まとめ

というわけで、RDSをスナップショットから復元する際に、発生する微妙な注意点をまとめました。
スナップショットを取っておいて、問題があったらワンクリックでロールバック!なんて都合の良い機能はないんだなぁって思うと、もう少し便利に使えないかなぁって思います(チラッチラッ
え?AWS CLI?そんなものありましたっけ?

今回はこんなところです。

参考

DB スナップショットからの復元

107
91
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
107
91

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?