表连续2次truncate后通过FLASHBACK没有恢复过来,通过调整哪些参数可以使用FLASHBACK命令进行恢复呢?

  • 【TiDB 版本】:4.0.5
  • 【问题描述】:一个表在被2次truncate后,通过FLASHBACK命令进行数据恢复,15小时后数据还没有恢复,表的数据量在90亿条记录左右.有什么地方可以查看恢复的状态吗?以及对2此truncate的表,使用FLASHBACK恢复的是2次truncate之间的数据吗?

执行 admin show ddl jobs where db_name='db_xxx' 100 拿一下对应的库的 ddl 操作记录看下

被truncate了3次,麻烦呀

请教下,把job_id:10168和10153的记录删除再进行FLASHBACK能够恢复吗?

MySQL [sg]> create table t(id int);
Query OK, 0 rows affected (0.10 sec)

MySQL [sg]> insert into t values(1);
Query OK, 1 row affected (0.03 sec)

MySQL [sg]> select * from t;
+------+
| id   |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

MySQL [sg]> truncate table t;
Query OK, 0 rows affected (0.13 sec)

MySQL [sg]> flashback table t to t1;
Query OK, 0 rows affected (1.17 sec)

MySQL [sg]> select * from t1;
+------+
| id   |
+------+
|    1 |
+------+
1 row in set (0.00 sec)

MySQL [sg]> insert into t values(2);
Query OK, 1 row affected (0.01 sec)

MySQL [sg]> select * from t;
+------+
| id   |
+------+
|    2 |
+------+
1 row in set (0.00 sec)

MySQL [sg]> truncate table t;
Query OK, 0 rows affected (0.12 sec)

MySQL [sg]> flashback table t to t2;
Query OK, 0 rows affected (1.19 sec)

MySQL [sg]> select * from t2;
+------+
| id   |
+------+
|    2 |
+------+
1 row in set (0.01 sec)

MySQL [sg]> admin show ddl jobs where db_name='sg';
+--------+---------+------------+----------------+--------------+-----------+----------+-----------+---------------------+---------------------+--------+
| JOB_ID | DB_NAME | TABLE_NAME | JOB_TYPE       | SCHEMA_STATE | SCHEMA_ID | TABLE_ID | ROW_COUNT | START_TIME          | END_TIME            | STATE  |
+--------+---------+------------+----------------+--------------+-----------+----------+-----------+---------------------+---------------------+--------+
|     85 | sg      | t2         | recover table  | public       |        76 |       80 |         0 | 2020-10-20 10:54:01 | 2020-10-20 10:54:02 | synced |
|     84 | sg      | t          | truncate table | public       |        76 |       80 |         0 | 2020-10-20 10:53:47 | 2020-10-20 10:53:47 | synced |
|     82 | sg      | t1         | recover table  | public       |        76 |       78 |         0 | 2020-10-20 10:53:22 | 2020-10-20 10:53:23 | synced |
|     81 | sg      | t          | truncate table | public       |        76 |       78 |         0 | 2020-10-20 10:52:56 | 2020-10-20 10:52:56 | synced |
|     79 | sg      | t          | create table   | public       |        76 |       78 |         0 | 2020-10-20 10:52:18 | 2020-10-20 10:52:18 | synced |
|     77 | sg      |            | create schema  | public       |        76 |        0 |         0 | 2020-10-20 10:52:10 | 2020-10-20 10:52:10 | synced |
+--------+---------+------------+----------------+--------------+-----------+----------+-----------+---------------------+---------------------+--------+
6 rows in set (0.01 sec)

我找了个测试环境测试了一下是可以的。麻烦拿一下 admin show ddl jobs where db_name='db_xxx' 100 的结果看下这个库之前都执行过什么 DDL ,以及目前的 flashback 语句处于什么状态。
输出结果最好可以截全,截图无法截全的话,最好以文本形式给下。

另外 admin show ddl jobs 显示的是 ddl 的执行记录,无法删除。

麻烦您truncate表2次后再通过FLASHBACK恢复测试下 ,1次truncate表后是能够通过FLASHBACK进行恢复的,2次truncate表后再通过FLASHBACK是不能恢复的


操作的记录比较多

truncate table 2 次之后 flashback 操作测试更新在上面了

admin show ddl jobs 的结果是否可以给下文本结果,从截图看到不到 state 字段,15 小时 flashback 没有恢复数据的话,如果当时执行 flashback 命令没有直接报错,那可能 DDL 还在执行过程中,需要通过 state 字段确认一下

这个是对应的truncate操作记录


这个是对应的恢复操作命令,第一次flashback是成功的,但是是没有数据,这个应该和多次truncate有关系,应该是恢复的后2次truncate之间时间内的数据记录了,所以数据为空


恢复异常应该是因为使用 flashback 多次恢复同一个被删除的表导致的,目前要恢复的话,可以考虑使用 dumpling 工具指定历史快照点的方式尝试恢复数据

https://docs.pingcap.com/zh/tidb/stable/dumpling-overview#导出-tidb-的历史数据快照

好的,我们再研究下

:+1:

@wanglw 可以用 recover 语句指定想要恢复的 truncate table 的数据。示例如下:

recover 语句的文档:https://docs.pingcap.com/zh/tidb/stable/sql-statement-recover-table#recover-table

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。