なぜこの記事を書いているのか?
- データベースのメンテナンスをしていたら、データベースの復元手順をメモったりしていないことに気づく。
 - データをすっ飛ばしたりした場合に、これではまずいなと思い整理してみることに。
 - 万一の時にササッと対応できるよう、簡潔にメモしておきたい。
 - 備えあれば憂いなし。
 
前提条件(環境)
下記の環境で作業を行うことを前提とした場合の手順です。
- 対象DBサーバ
 - AWS RDS 
MySQL Aurora 5.7.mysql_aurora.2.07.1 
mysql> select version();
+-----------+
| version() |
+-----------+
| 5.7.12    |
+-----------+
- 作業クライアント
macOS Catalina 10.15.3- 対象DBサーバにアクセスできるクライアントであることが前提です。
 - AWSのセキュリティグループのインバウンドルールで自分のIPアドレスを許可してアクセスできる状態にしておいてください。
 
 
$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.15.3
BuildVersion:   19D76
想定シナリオ
- mysqldumpを取得していない。(バックアップ運用計画をたてておきましょう)
 - なのにSQLのクエリをミスって必要なデータを削除してしまった。
 - わかっている人が一人しかいない。
 - その人がコロナウィルスに感染し、対応不能。
↑こういうことにならないように備えましょう。 
データが消えました!
まずは落ち着こう。
ユーザ名とパスワードを確認
- DBサーバにアクセスするにあたって必要です。
 - 1-PasswordやPassword Gorilla、社内ドキュメントを探しましょう。
 - 見つからない場合は、唯一の担当者に連絡するなどして確認しましょう。
↑こういうことにならないように備えましょう。 
AWSコンソール上での作業
- AWSコンソールからRDS -> スナップショット -> システムの順に進み、お目当てのスナップショットを選択
 - 右上の「アクション」プルダウンから「スナップショットの復元」を選択
 - DBエンジン: 
Aurora MySQL - DBエンジンのバージョン: 
Aurora(MySQL 5.7)2.07.1(default) - DBインスタンスのクラス: 復元作業が目的なので、お安い
db.t3.small - 2 vVPU, 2GiB RAM - DBインスタンス識別子: 何でも良いです。ただし本番稼働しているホストと似たような名前は避ける。作業対象を間違えないように。
 - Virtual Private Cloud (VPC): 確実にアクセスできるネットワーク環境を選択。わからなければ本番環境を参考に。
 - サブネットグループ:確実にアクセスできるネットワーク環境を選択。わからなければ本番環境を参考に。
 - パブリックアクセシビリティ: はい
 - アベイラビリティーゾーン: 確実にアクセスできるAZを選択。わからなければ本番環境を参考に。
 - データベースのポート:3306
 - DBパラメータグループ:わからなければ本番環境を参考に。
 - DBクラスタのパラメータグループ: わからなければ本番環境を参考に。
 - タグをスナップショットへコピー: チェックなし
 - バックトラックを無効にする
 - マスターキー: わからなければ本番環境を参考に。
 - ログのエクスポート:復元作業が目的なので不要
 - マイナーバージョン自動アップグレード: いいえ
-「DBインスタンスの復元」ボタンをクリック - AWSコンソール左側のメニューから「データベース」をクリック
 - スナップショットから復元したインスタンスのステータスが「利用可能」になるのを待つ
 - 利用可能になったら、
復元したインスタンスのDB識別子をクリック - 「エンドポイント」のホスト名を控える
 - 
データを復元したいインスタンス(データを削除してしまったインスタンス)のDB識別子をクリック - 「エンドポイント」のホスト名を控える
 
ターミナル上での作業
- 
スナップショットから復元したインスタンス上に残っているデータを下記のコマンドでdumpします - この記事では作業用クライアントがmacOSという想定ですので、「ターミナル」を起動し下記のコマンドを入力してください。
- 
hoge.c7mjpv6ouojj.ap-northeast-1.rds.amazonaws.comは先程のステップで控えたスナップショットから復元したインスタンスのホスト名に置き換えてください。 - 
adminの部分は最初に確認したユーザ名に置き換えてください。 - 
database_nameは復元したいデータベース名に置き換えてください。 
 - 
 
$ mysqldump --skip-column-statistics --set-gtid-purged=OFF -h hoge.c7mjpv6ouojj.ap-northeast-1.rds.amazonaws.com -u admin -p database_name > ./dump.sql
Enter password:
- 上記のコマンドを実行し、パスワードを入力するとカレントディレクトリにdump.sqlが出力されます。
 - このダンプファイルを
データを復元したいインスタンス(データを削除してしまったインスタンス)にインポートするために下記のコマンドを実行します。- 
hoge.c7mjpv6ouojj.ap-northeast-1.rds.amazonaws.comは先程のステップで控えたスナップショットから復元したインスタンスのホスト名に置き換えてください。 - 
adminの部分は最初に確認したユーザ名に置き換えてください。 - 
database_nameは復元したいデータベース名に置き換えてください。 
 - 
 
$ mysql -h hoge.c7mjpv6ouojj.ap-northeast-1.rds.amazonaws.com -u admin -p database_name < ./dump.sql
Enter password: 
データが復元したことを確認
- あくまでスナップショットの時点のデータです。
 - 復元できていないのは、どのデータなのかを把握する。
 - 復元できないことによって、誰にどのような影響が出ているのかを整理する。
 - 然るべき人に報告を入れる。
 
後片付け
- スナップショットから復元したインスタンスは削除しましょう。忘れるとどんどん課金されます。
 - 何がまずかったのかをしっかり振り返り、必要な情報を整理し、今回のトラブルを次に活かしましょう。