重要

現在表示されているページは、TiDBのアーカイブされたドキュメント (非更新) です。TiDBをご利用の場合、最新のLTS (Long Term Support) バージョンの使用を推奨します。

重要

このページは英語版のページを機械翻訳しています。原文はこちらからご覧ください。

フラッシュバック表

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 は、以前にドロップされたテーブルの ID と同じですt 。

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

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

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

MySQL の互換性

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