When the incremental backup only has DDL, the incremental restore has problems

[tongtongyin]

Please answer these questions before submitting your issue. Thanks!

1. What did you do?

If possible, provide a recipe for reproducing the error.
1.Create a table t1, do full backup to get backupData
2.Drop this table t1 , do incremental backup to get backupData-incr
3.Restore record in backupData
4. Restore record in backupData-incr
Note: Only one drop DDL operation between LastTS and backupTS.

2. What did you expect to see?

The database should drop table t1 after restore record in backupData-incr.

3. What did you see instead?

Table t1 still exists in the database after incremental recovery

4. What version of BR and TiDB/TiKV/PD are you using?

4.0.8

[3pointer]

This is by design. Only one drop table DDL won't work, in order to avoid data lost.
And if drop table & create table again, the origin drop DDL will be executed.

[tongtongyin]

But when I create an empty table, perform an incremental backup.
During incremental restoration, the newly created empty table cannot be restored.

[3pointer]

But when I create an empty table, perform an incremental backup.
During incremental restoration, the newly created empty table cannot be restored.

In my test with v4.0.9 br, the empty table can be restored during incremental restoration, could you please provide more details about the operation and br version?

[tongtongyin]

E.g:
Create an empty database test, create a table t1 in it, insert some data in table t1, and then perform a full backup to get backupData. The backup timestamp is TS1. Then create an empty table t2 in the test, without inserting any data, and perform incremental backup based on the timestamp TS1 to obtain backupDataIncr.

Delete the database test, first perform a full recovery based on backupData, and check that the table t1 exists in the database test. Then perform incremental recovery based on backupDataIncr, and check that the database test still has only table t1 and no table t2.

But there should be table t2.

[3pointer]

That's strange.
could you try tiup br validate decode --storage s3://tidb-test/BR/backupDataIncr and find the decode json file to see whether ddls field is nil?

[3pointer]

oh, I found this PR fixed it, but didn't cherry-pick to release-4.0, so master br doesn't has such problem. this fix will take into v4.0.10

[tongtongyin]

OK,THANKS

[3pointer]

#658 merged, so we can close this issue for now.