pingcap/tidb

Do not allow br full restore if table structure exists

Open

#32 615 ouverte le 24 févr. 2022

Voir sur GitHub
 (2 commentaires) (0 réactions) (0 assignés)Go (6 186 forks)batch import
component/brhelp wantedtype/feature-request

Métriques du dépôt

Stars
 (40 090 stars)
Métriques de merge PR
 (Merge moyen 14j 4h) (346 PRs mergées en 30 j)

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:

Guide contributeur

Direction de recherche
Étudiez le module BR (sauvegarde/restauration) dans le dépôt TiDB, en particulier la logique de restauration qui vérifie l'existence de la structure de la table. Examinez les fichiers sous `br/` ou `pkg/backup/` pour comprendre comment le processus de restauration gère actuellement l'existence de la table après une suppression par rapport à une troncature. Le problème suggère qu'une 'suppression' laisse la structure de la table tandis qu'une 'troncature' ne le fait pas, entraînant un comportement de restauration différent. L'objectif est d'ajouter un mécanisme de prévention qui bloque la restauration complète si la structure de la table existe toujours. Consultez les commentaires existants et toute PR associée (aucune liée) pour comprendre le comportement attendu.
Stack technique
go
Domaine
backenddatabase
Type d'issue
Fonctionnalité
DifficultéDifficulté estimée pour un nouveau contributeur, de 1 pour un très petit changement à 5 pour un travail expert.
3
Temps estiméFourchette de temps approximative pour investiguer, implémenter, tester et préparer une pull request.
1-2 jours
Statut d'activitéDisponibilité apparente de l'issue : fraîche, active, ancienne, bloquée ou en attente d'un mainteneur.
Active
ClartéClarté avec laquelle l'issue explique le changement attendu, les critères d'acceptation et la prochaine étape.
Claire
Prérequis
GoGit
Accessibilité débutantScore de 1 à 100 estimant l'accessibilité de cette issue pour un premier contributeur.
65