# FLASHBACK TABLE

+ Searches the specific time of `DROP` or `TRUNCATE` table
```
ADMIN SHOW DDL JOBS;
```

+ Set the `tidb_snapshot` variable to the specific time of DROP / TRUNCATE table
```
set @@tidb_snapshot="yyyy-mm-dd hh:mi:ss";
```

+ Execute FLASHBACK TABLE
```
FLASHBACK TABLE t [TO t1]
```
-----------------------------------------------------------------

When drop / truncate a table, TiDB only delete the table metadata, and writes the table data (row data and index data) to be deleted to the `mysql.gc_delete_range` table. The GC Worker in the TiDB background periodically removes from the `mysql.gc_delete_range` table the keys that exceed the GC lifetime.

Therefore, to recover a table, you only need to recover the table metadata and delete the corresponding row record in the `mysql.gc_delete_range` table before the GC Worker deletes the table data. You can use a snapshot read of TiDB to recover the table metadata. For details of snapshot read, refer to read historical data.

The following is the working process of FLASHBACK TABLE t TO t1:

1. TiDB searches the recent DDL history jobs and locates the first DDL operation of the DROP TABLE or the truncate table type on table t. If TiDB fails to locate one, an error is returned. Or users can searche the DDL history jobs by `ADMIN SHOW DDL JOBS` and choose the DDL operation by themself.

2. Checks whether the starting time of the DDL job is before `tikv_gc_safe_point`. If it is before `tikv_gc_safe_point`, it means that the table dropped by the `DROP` or `TRUNCATE` operation has been cleaned up by the `GC` and an error is returned.

3. Uses the starting time of the DDL job as the snapshot to read historical data and read table metadata.

4. Execute `FLASHBACK TABLE t TO t1`, TiDB deletes GC tasks related to table t in `mysql.gc_delete_range`.Then TiDB changes name in the table's metadata to t1, and uses this metadata to create a new table. Note that only the table name is changed but not the table ID. The table ID is the same as that of the previously dropped table t.

From the above process, you can see that TiDB always operates on the metadata of the table, and the user data of the table has never been modified. The recovered table t1 has the same ID as the previously dropped table t, so t1 can read the user data of t.