# Aurora DB クラスターのバックトラック
Amazon Aurora MySQL 互換エディション では、バックアップからデータを復元しないで、DB クラスターを特定の時刻までバックトラックできます。
**Contents**
+ [バックトラックの概要](#AuroraMySQL.Managing.Backtrack.Overview)
+ [バックトラックウィンドウ](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackWindow)
+ [バックトラック時間](#AuroraMySQL.Managing.Backtrack.Overview.BacktrackTime)
+ [バックトラックの制限事項](#AuroraMySQL.Managing.Backtrack.Limitations)
+ [利用可能なリージョンとバージョン](#AuroraMySQL.Managing.Backtrack.Availability)
+ [バックトラック対応クラスターのアップグレードに関する考慮事項](#AuroraMySQL.Managing.Backtrack.Upgrade)
+ [Aurora MySQL DB クラスターのバックトラックの設定](AuroraMySQL.Managing.Backtrack.Configuring.md)
+ [Aurora MySQL DB クラスターのバックトラックの実行](AuroraMySQL.Managing.Backtrack.Performing0.md)
+ [Aurora MySQL DB クラスターのバックトラックのモニタリング](AuroraMySQL.Managing.Backtrack.Monitoring.md)
+ [コンソールを使用したバックトラックイベントへのサブスクライブ](#AuroraMySQL.Managing.Backtrack.Event.Console)
+ [既存のバックトラックの取得](#AuroraMySQL.Managing.Backtrack.Retrieving)
+ [Aurora MySQL DB クラスターのバックトラックの無効化](AuroraMySQL.Managing.Backtrack.Disabling.md)
## バックトラックの概要
バックトラックは、指定した時間まで DB クラスターを「巻き戻し」ます。バックトラックは、DB クラスターをバックアップして特定の時点の状態に復元する操作に代わるものではありません。ただし、バックトラックは、従来のバックアップと復元に比べて、以下の利点があります。
+ 簡単にエラーを取り消すことができます。WHERE 句なしの DELETE などの破壊的なアクションを間違えて実行した場合、サービスの中断を最小限に抑えながら、破壊的なアクション以前の時点まで DB クラスターをバックトラックできます。
+ DB クラスターのバックトラックは迅速に実行できます。DB クラスターを特定の時点の状態に復元するには、新しい DB クラスターを起動し、これに対してバックアップデータや DB クラスターのスナップショットから復元する必要があり、時間がかかります。DB クラスターのバックトラックでは、新しい DB クラスターを作成せずに、DB クラスターを数分で巻き戻します。
+ 以前のデータの変更を調べることができます。DB クラスターを前後に繰り返しバックトラックして、特定のデータの変更がどの時点で発生したかを確認できます。例えば、DB クラスターを 3 時間前までバックトラックし、そこから 1 時間後まで戻すことができます。この場合、バックトラック時間は元の時間の 2 時間前となります。
**注記**
DB クラスターを特定の時点の状態に復元する方法については、「[Aurora DB クラスターのバックアップと復元の概要](Aurora.Managing.Backups.md)」を参照してください。
### バックトラックウィンドウ
バックトラックには、ターゲットバックトラックウィンドウと実際のバックトラックウィンドウがあります。
+ *ターゲットバックトラックウィンドウ*は、DB クラスターをバックトラックする所望時間です。*ターゲットバックトラックウィンドウ*は、バックトラックを有効化するときに指定します。例えば、DB クラスターを 1 日バックトラックする場合は、ターゲットバックトラックウィンドウとして 24 時間を指定します。
+ *実際のバックトラックウィンドウ*は、DB クラスターを実際にバックトラックできる時間であり、ターゲットバックトラックウィンドウより小さい値になることがあります。実際のバックトラックウィンドウは、ワークロードとストレージ (*変更レコード*と呼ばれるデータベースの変更に関する情報を保存) に基づきます。
バックトラックが有効になっている Aurora DB クラスターを更新すると、変更レコードが生成されます。Aurora は、ターゲットのバックトラックウィンドウの変更レコードを保持します。変更レコードの保存には利用料金 (時間単位) が発生します。DB クラスターのターゲットバックトラックウィンドウとワークロードの両方により、保存する変更レコード数が決まります。ワークロードは、特定の時間内に DB クラスターを変更する回数です。ワークロードが重い場合は、ワークロードが軽い場合と比べて、バックトラックウィンドウに保存される変更レコードが多くなります。
ターゲットバックトラックウィンドウは、DB クラスターをバックトラックできる最大の目標時間と考えることができます。通常、指定した最大時間までバックトラックできます。ただし、状況によっては、DB クラスターに保存できる変更レコードの数が少なくて、最大時間までバックトラックできない場合があります。この場合、実際のバックトラックウィンドウはターゲットより小さくなります。通常、DB クラスターのワークロードが非常に重い場合、実際のバックトラックウィンドウはターゲットより小さくなります。実際のバックトラックウィンドウがターゲットより小さい場合は、通知が送信されます。
DB クラスターのバックトラックが有効になっている場合、DB クラスターに保存されているテーブルを削除すると、そのテーブルは Aurora のバックトラック変更レコード内に保持されます。これにより、テーブルを削除する前の時点まで戻すことができます。バックトラックウィンドウ内のスペース不足でテーブルを保存できないと、テーブルは最終的にバックトラック変更レコードから削除される場合があります。
### バックトラック時間
Aurora は、常に DB クラスターに即した時間までバックトラックします。これにより、トランザクションがコミットされないままバックトラックが完了するという事態が避けられます。バックトラック時間を指定すると、Aurora はそれに即した最も近い時間を自動的に選択します。このアプローチでは、最終的なバックトラック時間が、指定した時間と正確に一致しない場合があります。正確なバックトラック時間は、AWS CLI の [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) コマンドを使用して確認できます。詳細については、「[既存のバックトラックの取得](#AuroraMySQL.Managing.Backtrack.Retrieving)」を参照してください。
### バックトラックの制限事項
バックトラックには以下の制限が適用されます。
+ バックトラックは、バックトラック機能を有効にして作成した DB クラスターでのみ使用できます。DB クラスターを変更せずにバックトラック機能を有効にすることはできません。バックトラック機能は、新しい DB クラスターの作成時または DB クラスターのスナップショットの復元時に有効化できます。
+ バックトトラックウィンドウの上限は 72 時間です。
+ バックトラックは、DB クラスター全体に影響します。例えば、1 つのテーブルや 1 つのデータ更新に限定してバックトラックすることはできません。
+ バックトラック対応クラスターからクロスリージョンリードレプリカを作成することはできませんが、クラスターでバイナリログ (binlog) レプリケーションを有効にすることはできます。バイナリログ記録が有効になっている DB クラスターをバックトラックしようとすると、バックトラックの強制を選択していない限り、通常はエラーが発生します。バックトラックを強制しようとすると、ダウンストリームのリードレプリカが壊れ、ブルー/グリーンデプロイなどの他のオペレーションが妨げられます。
+ データベースのクローンを、その作成時より前の時点までバックトラックすることはできません。ただし、元のデータベースを使用すると、クローン作成時より前の時点までバックトラックできます。データベースのクローンの詳細については、「[Amazon Aurora DB クラスターのボリュームのクローン作成](Aurora.Managing.Clone.md)」を参照してください。
+ バックトラックに伴って DB インスタンスがわずかに中断します。バックトラックオペレーションをスタートする前にアプリケーションを停止または一時停止し、新しい読み取り/書き込みリクエストを阻止する必要があります。Aurora は、バックトラックオペレーション時に、データベースを一時停止し、開いている接続をすべて閉じて、コミットされていない読み取りや書き込みをすべて削除します。その後、バックトラックオペレーションが完了するまで待ちます。
+ バックトラックをサポートしていない AWS リージョンでは、バックトラック対応クラスターのクロスリージョンスナップショットを復元できません。
+ バックトラック対応クラスターで Aurora MySQL バージョン 2 からバージョン 3 へのインプレースアップグレードを実行する場合、アップグレードを実行する前の時点にバックトラックすることはできません。
## 利用可能なリージョンとバージョン
バックトラックは Aurora PostgreSQL では使用できません。
Aurora MySQL によるバックトラックでサポートされているエンジンとリージョンは以下のとおりです。
| リージョン | Aurora MySQL バージョン 3 | Aurora MySQL バージョン 2 |
| --- | --- | --- |
| 米国東部 (バージニア北部) | すべてのバージョン | すべてのバージョン |
| 米国東部 (オハイオ) | すべてのバージョン | すべてのバージョン |
| 米国西部 (北カリフォルニア) | すべてのバージョン | すべてのバージョン |
| 米国西部 (オレゴン） | すべてのバージョン | すべてのバージョン |
| アフリカ (ケープタウン) | – | – |
| アジアパシフィック (香港) | – | – |
| アジアパシフィック (ジャカルタ) | – | – |
| アジアパシフィック (マレーシア) | – | – |
| アジアパシフィック (メルボルン) | – | – |
| アジアパシフィック (ムンバイ) | すべてのバージョン | すべてのバージョン |
| アジアパシフィック (ニュージーランド） | – | – |
| アジアパシフィック (大阪) | すべてのバージョン | バージョン 2.07.3 以降 |
| アジアパシフィック (ソウル) | すべてのバージョン | すべてのバージョン |
| アジアパシフィック (シンガポール) | すべてのバージョン | すべてのバージョン |
| アジアパシフィック (シドニー) | すべてのバージョン | すべてのバージョン |
| アジアパシフィック (台北) | – | – |
| アジアパシフィック (タイ) | – | – |
| アジアパシフィック (東京) | すべてのバージョン | すべてのバージョン |
| カナダ (中部) | すべてのバージョン | すべてのバージョン |
| カナダ西部 (カルガリー) | – | – |
| 中国 (北京) | – | – |
| 中国 (寧夏) | – | – |
| 欧州 (フランクフルト) | すべてのバージョン | すべてのバージョン |
| 欧州 (アイルランド) | すべてのバージョン | すべてのバージョン |
| 欧州 (ロンドン) | すべてのバージョン | すべてのバージョン |
| 欧州 (ミラノ) | – | – |
| 欧州 (パリ) | すべてのバージョン | すべてのバージョン |
| 欧州 (スペイン) | – | – |
| 欧州 (ストックホルム) | – | – |
| 欧州 (チューリッヒ) | – | – |
| イスラエル (テルアビブ) | – | – |
| メキシコ (中部) | – | – |
| 中東 (バーレーン) | – | – |
| 中東 (アラブ首長国連邦) | – | – |
| 南米 (サンパウロ) | – | – |
| AWS GovCloud (米国東部) | – | – |
| AWS GovCloud (米国西部) | – | – |
## バックトラック対応クラスターのアップグレードに関する考慮事項
Aurora MySQL バージョン 3 のすべてのマイナーバージョンがバックトラックについてサポートされているため、バックトラック対応 DB クラスターを Aurora MySQL バージョン 2 からバージョン 3 にアップグレードできます。
## コンソールを使用したバックトラックイベントへのサブスクライブ
次の手順では、コンソールを使用してバックトラックイベントにサブスクライブする方法を示します。実際のバックトラックウィンドウがターゲットバックトラックウィンドウより小さい場合、このイベントから E メール通知またはテキスト通知が送信されます。
**コンソールを使用してバックトラック情報を表示するには**
1. AWS マネジメントコンソール にサインインし、Amazon RDS コンソール ([https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/)) を開きます。
1. [**イベントサブスクリプション**] をクリックします。
1. [**イベントサブスクリプションを作成**] をクリックします。
1. [**名前** ] ボックスにイベントサブスクリプションの名前を入力し、[**有効**] で [**はい**] を必ず選択します。
1. [**ターゲット**] セクションで、[**新しい E メールトピック**] を選択します。
1. [**トピック名**] にトピックの名前を入力し、[**これらの受取人を含みます**] に通知を受け取る E メールアドレスまたは電話番号を入力します。
1. [**出典**] セクションで、[**出典タイプ**] として [**インスタンス**] を選択します。
1. [**含めるインスタンス**] で、[**特定のインスタンスを選択**] をクリックし、DB インスタンスを選択します。
1. [**含めるイベントカテゴリ**] で、[**特定のイベントカテゴリを選択**] をクリックし、[**バックトラック**] を選択します。
ページは次のように表示されます。
![\[バックトラックイベントサブスクリプション\]](http://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/images/aurora-backtrack-event.png)
1. [**作成**] を選択します。
## 既存のバックトラックの取得
DB クラスターの既存のバックトラックに関する情報を取得できます。この情報には、バックトラック固有の識別子、出典から/ターゲットへのバックトラック日時、バックトラックのリクエスト日時、バックトラックの現在のステータスが含まれます。
**注記**
現時点では、コンソールを使用して既存のバックトラックを取得することはできません。
### AWS CLI
次の手順では、AWS CLI を使用して DB クラスターの既存のバックトラックを取得する方法を示します。
**AWS CLI を使用して既存のバックトラックを取得するには**
+ AWS CLI の [describe-db-cluster-backtracks](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-cluster-backtracks.html) コマンドを呼び出して以下の値を渡します。
+ `--db-cluster-identifier` - DB クラスターの名前。
次の例では、`sample-cluster` の既存のバックトラックを取得します。
Linux、macOS、Unix の場合:
```
aws rds describe-db-cluster-backtracks \
--db-cluster-identifier sample-cluster
```
Windows の場合:
```
aws rds describe-db-cluster-backtracks ^
--db-cluster-identifier sample-cluster
```
### RDS API
Amazon RDS API を使用して DB クラスターのバックトラックに関する情報を取得するには、[DescribeDBClusterBacktracks](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusterBacktracks.html) オペレーションを使用します。このオペレーションでは、`DBClusterIdentifier` 値で指定した DB クラスターのバックトラックに関する情報を返します。