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

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

FLASHBACK TABLE構文は、TiDB4.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
FLASHBACKTABLETableNameFlashbackToNewName
TableName
Identifier.Identifier
FlashbackToNewName
TOIdentifier

ノート

テーブルがドロップされ、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の作業プロセスです:

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

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

ノート:

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

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

MySQLの互換性

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