Aurora MySQL の PITR 手順

こんにちは！コンサルティング部のくろすけです！

Aurora MySQL のデータリストア手順を作成するにあたり、ポイントインタイムリカバリ（以降、PITR）を実際に試してみました。
復元時に気をつけたいポイントがいくつかあったので、ご紹介します。

概要

Aurora の PITR は、バックアップ保持期間内の任意の時点のデータを、新しい DB クラスターとして復元する機能です。
他にも PITR の手順を紹介している記事がありましたが、下記が気になって試してみたので記事にしてみます。

事前に AWS re:Post を確認したところ、スナップショットからの復元では、リーダーインスタンスは復元後に手動で追加する必要がある旨が記載されていました。

また、新しいクラスターに復元した後に、必要なマルチアベイラビリティーゾーンのリーダーインスタンスを新しいクラスターに手動で追加して設定する必要があります。
Amazon Aurora MySQL スナップショットの復元に関する問題を解決する | AWS re:Post より抜粋

ですが、実際に PITR の復元画面を開いてみると、可用性と耐久性 の設定でリーダーを作成するかを選択できたため、実際に試してみました。

本記事では、この設定を含めて PITR の手順を一通り実施し、復元時の主な注意事項を整理します。

検証環境

データの投入と確認には、RDS Data API を利用するクエリエディタを使用しています。
踏み台サーバーなどを用意せずに、コンソールから SQL を実行できます。

やってみた

1. 検証用データを投入する

1. RDS コンソールの「クエリエディタ」で、復元元の DB クラスターに接続する
2. 下記の SQL を実行し、検証用のデータベースとテーブルを作成してデータを投入する

CREATE DATABASE IF NOT EXISTS restore_test;

CREATE TABLE IF NOT EXISTS restore_test.castles (
    id           INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY,
    castle_name  VARCHAR(50)  NOT NULL,
    prefecture   VARCHAR(10)  NOT NULL,
    city         VARCHAR(50)  NOT NULL,
    main_lord    VARCHAR(50)  NOT NULL,
    created_at   DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP,
    updated_at   DATETIME     NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
);

INSERT INTO restore_test.castles (castle_name, prefecture, city, main_lord) VALUES
    ('春日山城',   '新潟県', '上越市',     '上杉氏'),
    ('七尾城',     '石川県', '七尾市',     '畠山氏'),
    ('観音寺城',   '滋賀県', '近江八幡市', '六角氏'),
    ('小谷城',     '滋賀県', '長浜市',     '浅井氏'),
    ('月山富田城', '島根県', '安来市',     '尼子氏');

3. 下記の SQL を実行し、5 件のデータが登録されていることと、確認時刻（checked_at）を確認する

SELECT id, castle_name, prefecture, main_lord, NOW() AS checked_at
FROM restore_test.castles;

2. 誤操作を再現する

1. 下記の SQL を実行し、データの削除と、WHERE 句を付け忘れた更新を再現する

DELETE FROM restore_test.castles WHERE castle_name = '小谷城';

UPDATE restore_test.castles SET main_lord = '織田氏';

SELECT id, castle_name, main_lord, NOW() AS broken_at
FROM restore_test.castles;

2. データが更新されたことと、誤操作の時刻（broken_at）を確認する

3. 特定時点への復元を開始する

1. RDS コンソールの「データベース」で、復元元の DB クラスターを選択する
2. 「アクション」を選択する
3. 「特定時点への復元」を選択する

4. 復元の設定を行う

1. 「DB インスタンス識別子」に、復元後のライターインスタンスの名前を入力する

2. 「可用性と耐久性」で「別の AZ で Aurora レプリカ/リーダーノードを作成する」を選択する

3. 必要に応じて、その他の設定を変更する
4. 「特定時点への復元」を選択する

5. 復元の完了を確認する

1. 「データベース」で、復元した DB クラスター、ライターインスタンス、リーダーインスタンスが作成されていることを確認する

2. すべてのステータスが「利用可能」になったことを確認する

リーダーインスタンスも自動で作成されました。

6. マスター認証情報を Secrets Manager 管理に変更する

1. 「変更」を選択する
2. 「認証情報管理」で「AWS Secrets Manager で管理」を選択する

3. 「続行」を選択する
4. 「変更のスケジュール」で「すぐに適用」を選択し、「クラスターを変更」を選択する

7. RDS Data API を有効化する

1. 「データベース」で、復元した DB クラスターを選択する
2. 「アクション」を選択する
3. 「RDS Data API の有効化」を選択する
4. 確認画面で有効化を実行する

8. 復元したデータを確認する

1. 「クエリエディタ」で、復元した DB クラスターに接続する
   • 接続には、手順 6 で作成されたシークレットを使用する
2. 下記の SQL を実行し、誤操作前のデータに戻っていることを確認する

SELECT id, castle_name, prefecture, city, main_lord
FROM restore_test.castles
ORDER BY id;

誤操作前の値に戻っていることを確認できました。

まとめ

Aurora MySQL の PITR をマネジメントコンソールからやってみました。
今回の検証では、次の点を確認できました。

• リーダーインスタンスは復元時に作成できる
  AWS re:Post ではスナップショット復元について記載されていますが、PITR では復元画面で 可用性と耐久性 の設定によりリーダーインスタンスを同時に作成できることを確認しました。
• 復元画面の既定値には、復元元の設定が引き継がれない項目がある
  リーダーの作成、ログのエクスポート、RDS 延長サポートなど、復元元と異なる既定値の項目がありました。
  復元前に、復元元の設定と突き合わせる必要があります。
• 名前は DB インスタンス識別子から決まる
  DB クラスター識別子は入力した値に -cluster、リーダーインスタンスは -instance-2 を付けた名前になります。
  名称が決まっている場合は、復元後に名前を変更するなどの対応を検討してください。
• Secrets Manager での管理は復元後に設定する
  復元画面には設定項目がないため、復元後に DB クラスターの変更から有効化します。
• RDS Data API は復元後に有効化する
  復元した DB クラスターでは無効になっているため、クエリエディタなどで利用する場合は、復元後に有効化します。

あとがき

今回は、Aurora MySQL の PITR をやってみました！
この記事がどなたかのお役に立てれば幸いです。

以上、くろすけでした！