FLASHBACK TABLE

    查询集群的 tikv_gc_safe_point 和 tikv_gc_life_time。只要被 DROP 或 TRUNCATE 删除的表是在 tikv_gc_safe_point 时间之后，都能用 FLASHBACK TABLE 语法来恢复。 

    1. FLASHBACK TABLE table_name [TO other_table_name]

    FlashbackTableStmt:

    TableName:

    TableName

    如果删除了一张表并过了 GC lifetime，就不能再用 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 lifetime 一定要长于主集群的 GC lifetime。上下游同步存在的延迟可能也会造成下游恢复数据失败。

    如果 Binlog 同步出错，则需要在 Binlog 过滤掉该表，同时手动全量重新导入该表的数据。

    • 恢复被 DROP 删除的表数据：

    TiDB 在删除表时，实际上只删除了表的元信息，并将需要删除的表数据（行数据和索引数据）写一条数据到 mysql.gc_delete_range 表。TiDB 后台的 GC Worker 会定期从 mysql.gc_delete_range 表中取出超过 GC lifetime 相关范围的 key 进行删除。

    所以，FLASHBACK TABLE 只需要在 GC Worker 还没删除表数据前，恢复表的元信息并删除 mysql.gc_delete_range 表中相应的行记录即可。恢复表的元信息可以用 TiDB 的快照读实现。具体的快照读内容可以参考文档。下面是 FLASHBACK TABLE t TO t1 的工作流程：

    1. 从 DDL History job 中查找 drop table 或者 truncate table 类型的操作，且操作的表名是 t 的第一个 DDL job，若没找到，则返回错误。
    2. 检查 DDL job 的开始时间，是否在 tikv_gc_safe_point 之前。如果是tikv_gc_safe_point 之前，说明被 DROP 或 TRUNCATE 删除的表已经被 GC 清理掉，返回错误。
    3. 用 DDL job 的开始时间作为 snapshot 读取历史数据，读取表的元信息。
    4. 删除 中和表 t 相关的 GC 任务。

    可以发现，从表 t 被删除，到表 t 被 FLASHBACK 恢复到 t1，一直都是对表的元信息进行操作，而表的用户数据一直未被修改过。被恢复的表 t1 和之前被删除的表 t 的 table ID 相同，所以表 t1 才能读取表t 的用户数据。

    该语句是 TiDB 对 MySQL 语法的扩展。