pingcap/tidb

Do not allow br full restore if table structure exists

Open

#32,615 opened on Feb 24, 2022

View on GitHub
 (2 comments) (0 reactions) (0 assignees)Go (40,090 stars) (6,186 forks)batch import
component/brhelp wantedtype/feature-request

Description

Feature Request

Is your feature request related to a problem? Please describe:

Currently, when trying to br restore a table after run query "delete from t1;" and "truncate table t1;" is different:

CREATE TABLE `t1` (`a` int(11) NOT NULL,  PRIMARY KEY (`a`));
insert into t1 values (1), (2);
br backup t1;
delete from t1;
restore t1 => BR:Restore:ErrRestoreChecksumMismatch

CREATE TABLE `t1` (`a` int(11) NOT NULL,  PRIMARY KEY (`a`));
insert into t1 values (1), (2);
br backup t1;
truncate table t1;
restore t1 => Success

Describe the feature you'd like:

After execute query "delete from t1;" or "truncate table t1; br restore should not allow user to restore to the table t1, as table structure still exists in this cases.

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

Contributor guide

Tech stack
gosql
Domain
backenddatabase
Issue type
feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
stale
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
Understanding of TiDB backup/restore (BR)Go programming
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
20
Research direction
Investigate the BR (backup/restore) module in the TiDB repository, specifically the restore logic that checks for table structure existence. Look at the files under `br/` or `pkg/backup/` to understand how the restore process currently handles table existence after delete vs truncate. The issue suggests that a 'delete' leaves the table structure while 'truncate' does not, causing different restore behavior. The goal is to add a prevention mechanism that blocks full restore if the table structure still exists. Review existing comments and any related PRs (none linked) to understand the intended behavior.