見出し画像

［AWS］RDSのポイントインタイムリカバリ検証した

くさもちくん。はSE

先日、RDSのポイントインタイムリカバリ(特定時点への復旧)を実際に実行して検証しました。

その時沼った原因や、気になる設定値、使用したコマンドなどをここに記録します。


ポイントインタイムリカバリの仕組み

RDSでは自動で定期スナップショットをとることができます。
ポイントインタイムリカバリをするためには、まずこの定期自動スナップショットは必須になります。

また、RDSでは、ログスイッチは5分ごとに行われる。つまりアーカイブログは5分ごとに作られています。

ポイントインタイムリカバリを実行するときは、コンソールで戻したい時間とDBサーバの設定値を入れるだけです。

AWSで内部的に、定期のスナップショットに対して復旧したい時間までのアーカイブログが適用され、
復旧したい時間のDBインスタンスが復活します。(下図参照)

分かりにくい図、、

先ほど述べたように、アーカイブログは5分ごとに出されているので、最大直近５分前までリストア可能な仕様になっています。

コンソールから、「カスタム日時」で特定の時間を、「復元可能な最新時刻」で５分前をリストアできます。

以上がポイントインタイムリカバリの概要になります。


自分は、手動でアーカイブログを適用してリカバリテストを行った際、いろいろ失敗して上司を道連れに深夜まで残業したので、ぜんぶ内部的にやってくれるなんて素晴らしいと思いました👍　
時間だけ決めればいいなんて楽！！

テストの手順

実施したテストはシンプルなもので、以下です

①検証用にRDSを作成(oracle、標準作成)
②EC2からつないでデータベースにテストデータを挿入
⭐️
③30分以上経過してからテストデータ削除
④⭐️の時間を指定して、ポイントインタイムリカバリを実施
⑤新しいDBインスタンスでデータベースに接続し、削除されていたデータが復旧していることを確認する。　

データが復旧していたらリカバリテスト完了⭕️

※RDS作成時につなぎたいEC2を選択すると、勝手にSGもロールもやってくれたので大変楽でした。

沼つたポイント

④まで実施し、⑤で確認を行いました。

しかし、、、、
待てど暮らせど消したデータが戻ってこない。

なんでー！となって何度か別の方法で検証。
テーブルごと消してから復旧してみたりして、テーブルが復活するのに中身のデータが復活しないのを見て首をかしげていました。

理由はすぐにわかりました。

テストデータを挿入したとき、データベースの変更をコミットしてなかったからでした。
(あまりに初歩的すぎる、、、(;_:)）

データベースを操作するDML（Data Manipulation Language）のデータは、Commitまたはexitをすることで変更を確定します。
今回Commitもexitもしておらず、データが確定されていない情報として、アーカイブログには載っていなかったため、リストアされずに検証に失敗していました。

ちなみにテーブルだけ復元できていたのは、テーブル作成はDDL（Data Definition Language）のためコミット不要で、アーカイブログに載っていたためだと分かります。

ちなみにこのDDL、DMLはデータベースエンジンによって異なるようです。


下記にOracleのコミットに関する参考文献を張っておきます。
データベースはまだまだ勉強が必要そうです。


初歩的なミスですが忘れてしまいがちかもしれません。おかげで2時間ほど無駄にしました。忘れないようにしようと思います。

コミットして再度検証実行すると、無事復旧されて検証は成功しました。

「テストデータを挿入したらCOMMIT;する！！！
DMLデータはコミットしないとデータが反映されない！！」　


気になる設定値

1. DBインスタンス識別子

ポイントインタイムリカバリをする際、
DBインスタンス識別子を決めます。

多くの場合、その識別子はリストアしたい元々のDBインスタンスと同じであると思います。
しかし、
DBインスタンス識別子は、同じAWSアカウント内に一位でなければいけないため、元のインスタンスと同じ名前はつけられないです。
違う名前をつける必要があります。

ただ、
障害が発生したDBインスタンスの名前を変えてから、もとと同じ名前でリストアするなどの方法で対処できます👏

また、DBインスタンス識別子の名前は作成後からも変更可能なので、障害が発生したもとのインスタンスを削除した後に名前を変更することもできます。

識別子は後から変更できないだろうと思っていたので、意外だったポイントです。

2. 証明機関
RDSとその他のサービス、クライアント等が通信する際に暗号化する場合、証明書が必要になります。このパラメータではその証明書を選択するのですが、古い設計書なとでは証明書の期限が切れていたりするので、適宜新しい証明書を選択することか必要になります。


3. データベース名と最初のデータベース名の違い

ポイントインタイムリカバリの際、データベース名と最初のデータベース名を指定します。
テスト中このふたつの違いがとても気になりました。

調べてみたけどよくわからず、色々触って確かめることに。

①下記状態で復元
データベース名：TEST
最初のデータベース名：ORCL
予想：
この状態で復元して、ORCLでつなげなくてTESTで繋げたら
データベース名は新しく作るデータベース名で、最初のデータベース名は参照元の名前なのではないか

結果：
ORCLでは接続不可。TESTで接続できた。中身も復旧されている。
TESTという名前のデータベースで、復旧したのか？
データベースの名前だけが変わっている？

②下記状態で復元
データベース名：ORCL
最初のデータベース名：TEST
予想：
最初のデータベース名が、参照元のデータベース名を表すなら、そもそも復旧できないか、復旧しても中身がないはず

結果：
TESTで接続できなくて、ORCLで接続できた。
中身は復旧されていた。

いろいろやって調べてみましたが、現時点であまりよくわかっていません。
引き続き調べようと思いますが今回は時間がなかったのでここまでになりました。


4. RDSエンドポイント
新しくDBインスタンスを作ると、DBインスタンス識別子を含んだ「RDSエンドポイント」が変更されます。
このエンドポイントは、データベースに接続する時に使うものなので、
新しくした場合はこのエンドポイントを使用している所に影響が及ぶのは押さえておいた方がよいでしょう。
（RDSエンドポイントは、DBインスタンス識別子が変化する場合に変化するため、障害が発生したDBインスタンスの名前を変えてから、もとと同じ名前で復旧した場合は、RDSエンドポイントは変化しないようです。以下参考）



検証で使用したコマンド

$ sqlplus <マスターユーザ名>/<マスターユーザのパスワード>@<エンドポイント>:1521/<DB名>

↑ データベース接続用sql


まとめ

データベースはコミットしよう。
ポイントインタイムリカバリ自体はとても簡単。


この記事が気に入ったらサポートをしてみませんか？