フラッシュバックテーブル

FLASHBACK TABLE構文は TiDB 4.0 以降に導入されました。 FLASHBACK TABLEステートメントを使用すると、ガベージコレクション (GC) の存続期間内にDROPまたはTRUNCATE操作によって削除されたテーブルとデータを復元できます。

システム変数tidb_gc_life_time (デフォルト: 10m0s ) は、以前のバージョンの行の保持時間を定義します。ガベージコレクションが実行された現在のsafePointの場所は、次のクエリで取得できます。

SELECT * FROM mysql.tidb WHERE variable_name = 'tikv_gc_safe_point';

tikv_gc_safe_point回の経過後にDROPまたはTRUNCATEステートメントによってテーブルが削除された限り、 FLASHBACK TABLEステートメントを使用してテーブルを復元できます。

構文

FLASHBACK TABLE table_name [TO other_table_name]

あらすじ

FlashbackTableStmt
TableName
FlashbackToNewName

FlashbackTableStmt ::=
    'FLASHBACK' 'TABLE' TableName FlashbackToNewName

TableName ::=
    Identifier ( '.' Identifier )?

FlashbackToNewName ::=
    ( 'TO' Identifier )?

ノート

テーブルが削除され、GC 有効期間が経過した場合、 FLASHBACK TABLEステートメントを使用して削除されたデータを回復することはできなくなります。それ以外の場合は、 Can't find dropped / truncated table 't' in GC safe point 2020-03-16 16:34:52 +0800 CSTのようなエラーが返されます。

TiDB Binlog を有効にしてFLASHBACK TABLEステートメントを使用する場合は、次の条件と要件に注意してください。

ダウンストリームのセカンダリクラスターもFLASHBACK TABLEをサポートする必要があります。
セカンダリクラスターの GC ライフタイムは、プライマリクラスターの GC ライフタイムよりも長くする必要があります。
アップストリームとダウンストリーム間のレプリケーションの遅延により、ダウンストリームへのデータの回復に失敗する可能性もあります。
TiDB Binlogがテーブルを複製しているときにエラーが発生した場合は、TiDB Binlogでそのテーブルをフィルタリングし、そのテーブルのすべてのデータを手動でインポートする必要があります。

例

DROPの操作によって削除されたテーブルデータを復元します。
```
DROP TABLE t;
```
```
FLASHBACK TABLE t;
```
TRUNCATEの操作で削除されたテーブルデータを回復します。切り詰められたテーブルtはまだ存在するため、リカバリするテーブルtの名前を変更する必要があります。そうしないと、テーブルtがすでに存在するため、エラーが返されます。
```
TRUNCATE TABLE t;
```
```
FLASHBACK TABLE t TO t1;
```

実施原則

テーブルを削除する場合、TiDB はテーブルのメタデータのみを削除し、削除するテーブルデータ (行データおよびインデックスデータ) をmysql.gc_delete_rangeのテーブルに書き込みます。 TiDB バックグラウンドの GC ワーカーは、GC の有効期間を超えたキーをmysql.gc_delete_rangeテーブルから定期的に削除します。

したがって、テーブルを回復するには、GC ワーカーがテーブルデータを削除する前に、テーブルのメタデータを回復し、テーブルmysql.gc_delete_range内の対応する行レコードを削除するだけで済みます。 TiDB のスナップショット読み取りを使用して、テーブルのメタデータを回復できます。スナップショットリードの詳細については、履歴データの読み取りを参照してください。

FLASHBACK TABLE t TO t1の作業工程は以下の通りです。

TiDB は、最近の DDL 履歴ジョブを検索し、テーブルtでタイプDROP TABLEまたはタイプtruncate tableの最初の DDL 操作を見つけます。 TiDB が見つからない場合は、エラーが返されます。
TiDB は、DDL ジョブの開始時刻がtikv_gc_safe_pointより前であるかどうかをチェックします。 tikv_gc_safe_pointより前の場合は、 DROPまたはTRUNCATE操作によって削除されたテーブルが GC によってクリーンアップされ、エラーが返されたことを意味します。
TiDB は、DDL ジョブの開始時間をスナップショットとして使用して、履歴データを読み取り、テーブルのメタデータを読み取ります。
TiDB は、 mysql.gc_delete_rangeのテーブルtに関連する GC タスクを削除します。
TiDB は、テーブルのメタデータのname t1に変更し、このメタデータを使用して新しいテーブルを作成します。テーブル名のみが変更され、テーブル ID は変更されないことに注意してください。テーブル ID は、以前に削除されたテーブルtの ID と同じです。

上記のプロセスから、TiDB は常にテーブルのメタデータに対して動作し、テーブルのユーザーデータは決して変更されていないことがわかります。復元されたテーブルt1は、以前に削除されたテーブルtと同じ ID を持っているため、 t1 tのユーザーデータを読み取ることができます。

注記：
復元されたテーブルの ID は削除されたテーブルの ID と同じであり、TiDB ではすべての既存のテーブルがグローバルに一意のテーブル ID を持つ必要があるため、 FLASHBACKステートメントを使用して同じ削除されたテーブルを複数回復元することはできません。

FLASHBACK TABLE操作は、TiDB がスナップショット読み取りを通じてテーブルメタデータを取得し、その後CREATE TABLEと同様のテーブル作成プロセスを経ることによって実行されます。したがって、 FLASHBACK TABLEは本質的には一種の DDL 操作です。

MySQLの互換性

このステートメントは、MySQL 構文に対する TiDB 拡張機能です。

フラッシュバックテーブル

構文

あらすじ

ノート

例

実施原則

MySQLの互換性

このページは役に立ちましたか？