フラッシュバックテーブル
FLASHBACK TABLE構文は TiDB 4.0 以降で導入されました。3 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 はテーブルのメタデータの
namet1に変更し、このメタデータを使用して新しいテーブルを作成します。テーブル名のみが変更され、テーブル 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 拡張です。