Aurora DB クラスターのバックトラック
Amazon Aurora MySQL 互換エディション では、バックアップからデータを復元しないで、DB クラスターを特定の時刻までバックトラックできます。
バックトラックの概要
バックトラックは、指定した時間まで DB クラスターを「巻き戻し」ます。バックトラックは、DB クラスターをバックアップして特定の時点の状態に復元する操作に代わるものではありません。ただし、バックトラックは、従来のバックアップと復元に比べて、以下の利点があります。
簡単にエラーを取り消すことができます。WHERE 句なしの DELETE などの破壊的なアクションを間違えて実行した場合、サービスの中断を最小限に抑えながら、破壊的なアクション以前の時点まで DB クラスターをバックトラックできます。
DB クラスターのバックトラックは迅速に実行できます。DB クラスターを特定の時点の状態に復元するには、新しい DB クラスターを起動し、これに対してバックアップデータや DB クラスターのスナップショットから復元する必要があり、時間がかかります。DB クラスターのバックトラックでは、新しい DB クラスターを作成せずに、DB クラスターを数分で巻き戻します。
以前のデータの変更を調べることができます。DB クラスターを前後に繰り返しバックトラックして、特定のデータの変更がどの時点で発生したかを確認できます。例えば、DB クラスターを 3 時間前までバックトラックし、そこから 1 時間後まで戻すことができます。この場合、バックトラック時間は元の時間の 2 時間前となります。
注記
DB クラスターを特定の時点の状態に復元する方法については、「Aurora DB クラスターのバックアップと復元の概要」を参照してください。
バックトラックウィンドウ
バックトラックには、ターゲットバックトラックウィンドウと実際のバックトラックウィンドウがあります。
-
ターゲットバックトラックウィンドウは、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 コマンドを使用して確認できます。詳細については、「既存のバックトラックの取得」を参照してください。
バックトラックの制限事項
バックトラックには以下の制限が適用されます。
-
バックトラックは、バックトラック機能を有効にして作成した DB クラスターでのみ使用できます。バックトラック機能は、新しい DB クラスターの作成時または DB クラスターのスナップショットの復元時に有効化できます。バックトラック機能を有効化して作成された DB クラスターには、バックトラック機能を有効化してクローンの DB クラスターを作成することができます。現在、バックトラック機能を無効にして作成された DB クラスターでバックトラックを実行することはできません。
-
バックトトラックウィンドウの上限は 72 時間です。
-
バックトラックは、DB クラスター全体に影響します。例えば、1 つのテーブルや 1 つのデータ更新に限定してバックトラックすることはできません。
-
バックトラックでは、バイナリログ (binlog) のレプリケーションがサポートされません。バックトラックを設定または使用する前に、クロスリージョンレプリケーションを無効化する必要があります。
-
データベースのクローンを、その作成時より前の時点までバックトラックすることはできません。ただし、元のデータベースを使用すると、クローン作成時より前の時点までバックトラックできます。データベースのクローンの詳細については、「Amazon Aurora DB クラスターのボリュームのクローン作成」を参照してください。
-
バックトラックに伴って 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 にアップグレードできます。
バックトラックの設定
バックトラック機能を使用するには、バックトラックを有効にしてターゲットバックトラックウィンドウを指定する必要があります。それ以外の場合、バックトラックは無効です。
ターゲットのバックトラックウィンドウでは、バックトラックを使用してデータベースを巻き戻したい時間の長さを指定します。Aurora は、その時間枠をサポートするのに十分な変更レコードを保持しようと試みます。
コンソールを使用して、新しい DB クラスターの作成時にバックトラックを設定できます。DB クラスターを変更して、バックトラック対応クラスターのバックトラックウィンドウを変更することもできます。バックトラックウィンドウを 0 に設定してクラスターのバックトラックを完全に無効にすると、そのクラスターでバックトラックを再度有効にすることはできません。
DB クラスターの作成時にコンソールでバックトラックを設定する
新しい Aurora MySQL DB クラスターの作成時にバックトラックを設定するには、[Enable Backtrack (バックトラックの有効化)] を選択し、[Target Backtrack window (ターゲットバックトラックウィンドウ)] 値としてゼロより大きい値を [Backtrack (バックトラック)] セクションに指定します。
DB クラスターを作成するには、「Amazon Aurora DB クラスターの作成」の手順に従います。次のイメージは [Backtrack (バックトラック)] セクションを示しています。

新しい DB クラスターを作成した時点では、Aurora には DB クラスターのワークロード用のデータがありません。したがって、新しい DB クラスターのコストを具体的に見積もることはできません。コンソールでは、代わりに一般的なワークロードに基づいて、指定したターゲットバックトラックウィンドウの一般的なユーザーコストを提示します。一般的なコストは、バックトラック機能のコストを見積もるための一般的な参考として提供されます。
重要
実際のコストは、DB クラスターのワークロードに基づくため、一般的なコストとは一致しない場合があります。
DB クラスターの変更時にコンソールでバックトラックを設定する
コンソールを使用して DB クラスターのバックトラックを変更できます。
注記
現時点では、バックトラック機能が有効になっている DB クラスターに限り、バックトラックを変更できます。バックトラック機能を無効にして作成した DB クラスターや後でバックトラック機能を無効にした DB クラスターでは、[バックトラック] 機能が表示されません。
コンソールを使用して DB クラスターのバックトラックを変更するには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
[データベース] をクリックします。
-
変更するクラスターを選択し、[変更] を選択します。
-
[Target Backtrack window (ターゲットバックトラックウィンドウ)] で、バックトラックする所望時間を変更します。上限は 72 時間です。
コンソールは、DB クラスターの過去のワークロードに基づいて、指定した時間のコストを見積もります。
-
DB クラスターでバックトラックが無効になっている場合は、Amazon CloudWatch の DB クラスターの
VolumeWriteIOPS
メトリクスに基づいてコストを見積もります。 -
DB クラスターでバックトラックが以前に有効化されている場合は、Amazon CloudWatch の DB クラスターの
BacktrackChangeRecordsCreationRate
メトリクスに基づいてコストを見積もります。
-
-
[Continue] (続行) をクリックします。
-
[Scheduling of Modifications (変更の予定)] で、以下のいずれかを選択します。
-
Apply during the next scheduled maintenance window (次回予定のメンテナンスウィンドウで適用する) - 次回のメンテナンスウィンドウまで待ってから [Target Backtrack window (ターゲットバックトラックウィンドウ)] の変更を適用します。
-
Apply immediately (即時に適用する) - [Target Backtrack window (ターゲットバックトラックウィンドウ)] の変更をできるだけ早急に適用します。
-
-
[Modify cluster] (クラスターの変更) を選択します。
AWS CLI の create-db-cluster コマンドを使用して新しい Aurora MySQL DB クラスターを作成する場合、バックトラックを設定するには、ゼロより大きい --backtrack-window
値を指定します。--backtrack-window
値は、ターゲットバックトラックウィンドウを指定します。詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。
以下の --backtrack-window
CLI コマンドを使用して AWS 値を指定することもできます。
次の手順では、AWS CLI を使用して DB クラスターのターゲットバックトラックウィンドウを変更する方法を示します。
AWS CLI を使用して DB クラスターのターゲットバックトラックウィンドウを変更するには
-
AWS CLI の modify-db-cluster コマンドを呼び出して以下の値を指定します。
-
--db-cluster-identifier
- DB クラスターの名前。 -
--backtrack-window
- DB クラスターをバックトラックする所望の最大秒数。
次の例では、
sample-cluster
のターゲットバックトラックウィンドウを 1 日 (86,400 秒) に設定します。Linux、macOS、Unix の場合:
aws rds modify-db-cluster \ --db-cluster-identifier sample-cluster \ --backtrack-window 86400
Windows の場合:
aws rds modify-db-cluster ^ --db-cluster-identifier sample-cluster ^ --backtrack-window 86400
-
注記
現在、バックトラックを有効化できるのは、バックトラック機能を有効にして作成した DB クラスターに限ります。
CreateDBCluster Amazon RDS API オペレーションを使用して新しい Aurora MySQL DB クラスターを作成する場合、バックトラックを設定するには、ゼロより大きい BacktrackWindow
値を指定します。BacktrackWindow
値は、DBClusterIdentifier
値で指定した DB クラスターのターゲットバックトラックウィンドウを指定します。詳細については、「Amazon Aurora DB クラスターの作成」を参照してください。
以下の API オペレーションを使用して BacktrackWindow
値を指定することもできます。
注記
現在、バックトラックを有効化できるのは、バックトラック機能を有効にして作成した DB クラスターに限ります。
バックトラックの実行
DB クラスターは、指定したバックトラックタイムスタンプまでバックトラックできます。バックトラックタイムスタンプが、最も早いバックトラック時間から現時点までの範囲内にあれば、DB クラスターはそのタイムスタンプまでバックトラックされます。
それ以外の場合は、通常、エラーが発生します。また、バイナリログが有効になっている DB クラスターをバックトラックしようとすると、通常、エラーが発生します。ただし、バックトラックの強制実行を選択した場合を除きます。バックトラックの強制実行は、バイナリログを使用する他のオペレーションに干渉する場合があります。
重要
バックトラックでは、それに伴う変更の binlog エントリが生成されません。DB クラスターでバイナリログを有効にしている場合、バックトラックは binlog 実装と互換性がない可能性があります。
注記
データベースのクローンでは、クローンの作成日時より前の時点まで DB クラスターをバックトラックすることはできません。データベースのクローンの詳細については、「Amazon Aurora DB クラスターのボリュームのクローン作成」を参照してください。
次の手順では、コンソールを使用して DB クラスターのバックトラックオペレーションを実行する方法を示します。
コンソールを使用してバックトラックオペレーションを実行するには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
ナビゲーションペインで、[インスタンス] を選択します。
-
バックトラックする DB クラスターのプライマリインスタンスを選択します。
-
[アクション] で、[DB クラスターのバックトラック] を選択します。
-
[DB クラスターのバックトラック] ページで、DB クラスターのバックトラック先のバックトラックタイムスタンプを入力します。
-
[Backtrack DB cluster (DB クラスターのバックトラック)] を選択します。
次の手順では、AWS CLI を使用して DB クラスターをバックトラックする方法を示します。
AWS CLI を使用して DB クラスターをバックトラックするには
-
AWS CLI の backtrack-db-cluster コマンドを呼び出して以下の値を渡します。
-
--db-cluster-identifier
- DB クラスターの名前。 -
--backtrack-to
- DB クラスターをバックトラックする先のバックトラックタイムスタンプ (ISO 8601 形式で指定)。
次の例では、DB クラスター
sample-cluster
を 2018 年 3 月 19 日午前 10 時までバックトラックします。Linux、macOS、Unix の場合:
aws rds backtrack-db-cluster \ --db-cluster-identifier sample-cluster \ --backtrack-to 2018-03-19T10:00:00+00:00
Windows の場合:
aws rds backtrack-db-cluster ^ --db-cluster-identifier sample-cluster ^ --backtrack-to 2018-03-19T10:00:00+00:00
-
Amazon RDS API を使用して DB クラスターをバックトラックするには、BacktrackDBCluster オペレーションを使用します。このオペレーションでは、DBClusterIdentifier
値で指定した DB クラスターを、指定した時間までバックトラックします。
バックトラックのモニタリング
DB クラスターのバックトラック情報を表示し、バックトラックのメトリクスをモニタリングできます。
コンソールを使用してバックトラック情報を表示し、バックトラックのメトリクスをモニタリングするには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
[データベース] をクリックします。
-
情報を表示する DB クラスターの名前を選択します。
バックトラック情報は [Backtrack (バックトラック)] セクションにあります。
バックトラックが有効になっていると、以下の情報が表示されます。
-
Target window (ターゲットウィンドウ) - ターゲットバックトラックウィンドウとして現在指定されている時間。十分なストレージがある場合、ターゲットはバックトラックできる最大時間です。
-
Actual window (実際のウィンドウ) - 実際にバックトラックできる時間であり、ターゲットバックトラックウィンドウより小さい値になることがあります。実際のバックトラックウィンドウは、ワークロードと、バックトラック変更レコードを保持できるストレージに基づきます。
-
Earliest backtrack time (最も早いバックトラック時間) - DB クラスターの最も早い (可能な限り) バックトラック時間。表示された時間より前の時点まで DB クラスターをバックトラックすることはできません。
-
-
DB クラスターのバックトラックのメトリクスを表示するには、以下の操作を行います。
-
ナビゲーションペインで、[インスタンス] を選択します。
-
詳細を表示する DB クラスターのプライマリインスタンス名を選択します。
-
[CloudWatch] セクションで、[CloudWatch] ボックスに
Backtrack
と入力し、バックトラックのメトリクスのみを表示します。以下のメトリクスが表示されます。
-
バックトラック変更レコードの作成率 (カウント) - このメトリクスは、DB クラスターで 5 分間に作成されたバックトラック変更レコードの数を示します。このメトリクスを使用して、ターゲットバックトラックウィンドウのバックトラックコストを見積もることができます。
-
[課金済み] 保存されたバックトラック変更レコード数 (カウント) - このメトリクスは、DB クラスターで実際に使用されたバックトラック変更レコードの数を示します。
-
実際のバックトラックウィンドウ (分数) - このメトリクスは、ターゲットバックトラックウィンドウと実際のバックトラックウィンドウの間に差異があるかどうかを示します。例えば、ターゲットバックトラックウィンドウが 2 時間 (120 分) で、このメトリクスで示された実際のバックトラックウィンドウが 100 分の場合、実際のバックトラックウィンドウはターゲットよりも小さくなります。
-
バックトラックウィンドウのアラート (カウント) - このメトリクスは、特定の時間内に実際のバックトラックウィンドウがターゲットバックトラックウィンドウより小さくなった回数を示します。
注記
以下のメトリクスは、現在の時刻より遅れる場合があります。
-
バックトラック変更レコードの作成率 (カウント)
-
[課金済み] 保存されたバックトラック変更レコード (カウント)
-
-
次の手順では、AWS CLI を使用して DB クラスターのバックトラック情報を表示する方法を示します。
AWS CLI を使用して DB クラスターのバックトラック情報を表示するには
-
AWS CLI の describe-db-clusters コマンドを呼び出して以下の値を渡します。
-
--db-cluster-identifier
- DB クラスターの名前。
次の例では、
sample-cluster
のバックトラック情報を一覧表示します。Linux、macOS、Unix の場合:
aws rds describe-db-clusters \ --db-cluster-identifier sample-cluster
Windows の場合:
aws rds describe-db-clusters ^ --db-cluster-identifier sample-cluster
-
Amazon RDS API を使用して DB クラスターのバックトラック情報を表示するには、DescribeDBClusters オペレーションを使用します。このオペレーションでは、DBClusterIdentifier
値で指定した DB クラスターのバックトラック情報を返します。
コンソールを使用したバックトラックイベントへのサブスクライブ
次の手順では、コンソールを使用してバックトラックイベントにサブスクライブする方法を示します。実際のバックトラックウィンドウがターゲットバックトラックウィンドウより小さい場合、このイベントから E メール通知またはテキスト通知が送信されます。
コンソールを使用してバックトラック情報を表示するには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
[イベントサブスクリプション] をクリックします。
-
[イベントサブスクリプションを作成] をクリックします。
-
[名前 ] ボックスにイベントサブスクリプションの名前を入力し、[有効] で [はい] を必ず選択します。
-
[ターゲット] セクションで、[新しい E メールトピック] を選択します。
-
[トピック名] にトピックの名前を入力し、[これらの受取人を含みます] に通知を受け取る E メールアドレスまたは電話番号を入力します。
-
[出典] セクションで、[出典タイプ] として [インスタンス] を選択します。
-
[含めるインスタンス] で、[特定のインスタンスを選択] をクリックし、DB インスタンスを選択します。
-
[含めるイベントカテゴリ] で、[特定のイベントカテゴリを選択] をクリックし、[バックトラック] を選択します。
ページは次のように表示されます。
-
[作成] を選択します。
既存のバックトラックの取得
DB クラスターの既存のバックトラックに関する情報を取得できます。この情報には、バックトラック固有の識別子、出典から/ターゲットへのバックトラック日時、バックトラックのリクエスト日時、バックトラックの現在のステータスが含まれます。
注記
現時点では、コンソールを使用して既存のバックトラックを取得することはできません。
次の手順では、AWS CLI を使用して DB クラスターの既存のバックトラックを取得する方法を示します。
AWS CLI を使用して既存のバックトラックを取得するには
-
AWS CLI の describe-db-cluster-backtracks コマンドを呼び出して以下の値を渡します。
-
--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
-
Amazon RDS API を使用して DB クラスターのバックトラックに関する情報を取得するには、DescribeDBClusterBacktracks オペレーションを使用します。このオペレーションでは、DBClusterIdentifier
値で指定した DB クラスターのバックトラックに関する情報を返します。
DB クラスターのバックトラックの無効化
DB クラスターのバックトラック機能を無効にすることができます。
コンソールを使用して DB クラスターのバックトラックを無効にすることができます。クラスターのバックトラックを完全に無効にした後に、そのクラスターに対して再度有効にすることはできません。
コンソールを使用して DB クラスターのバックトラック機能を無効にするには
AWS Management Console にサインインし、Amazon RDS コンソール (https://console.aws.amazon.com/rds/
) を開きます。 -
[データベース] をクリックします。
-
変更するクラスターを選択し、[変更] をクリックします。
-
[バックトラック] セクションで、[バックトラックを無効にする] をクリックします。
-
[Continue] (続行) をクリックします。
-
[Scheduling of Modifications (変更の予定)] で、以下のいずれかを選択します。
-
次回の定期メンテナンス期間中に適用 - 次回のメンテナンスウィンドウまで待ってから変更を適用します。
-
すぐに適用 - 変更をできるだけ早急に適用します。
-
-
[クラスターの変更] をクリックします。
AWS CLI を使用して DB クラスターのバックトラック機能を無効にするには、ターゲットバックトラックウィンドウを 0
(ゼロ) に設定します。クラスターのバックトラックを完全に無効にした後に、そのクラスターに対して再度有効にすることはできません。
AWS CLI を使用して DB クラスターのターゲットバックトラックウィンドウを変更するには
-
AWS CLI の modify-db-cluster コマンドを呼び出して以下の値を指定します。
-
--db-cluster-identifier
- DB クラスターの名前。 -
--backtrack-window
- バックトラックをオフにするには、0
を指定します。
次の例では、
sample-cluster
のバックトラック機能を無効化するために--backtrack-window
を0
に設定します。Linux、macOS、Unix の場合:
aws rds modify-db-cluster \ --db-cluster-identifier sample-cluster \ --backtrack-window 0
Windows の場合:
aws rds modify-db-cluster ^ --db-cluster-identifier sample-cluster ^ --backtrack-window 0
-
Amazon RDS API を使用して DB クラスターのバックトラック機能を無効にするには、ModifyDBCluster オペレーションを使用します。BacktrackWindow
値を 0
(ゼロ) に設定し、DBClusterIdentifier
値に DB クラスターを指定します。クラスターのバックトラックを完全に無効にした後に、そのクラスターに対して再度有効にすることはできません。