pingcap/tidb

Do not allow br full restore if table structure exists

Open

#32.615 aberto em 24 de fev. de 2022

Ver no GitHub
 (2 comments) (0 reactions) (0 assignees)Go (6.186 forks)batch import
component/brhelp wantedtype/feature-request

Métricas do repositório

Stars
 (40.090 stars)
Métricas de merge de PR
 (Mesclagem média 14d 4h) (346 fundiu PRs em 30d)

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:

Guia do colaborador

Direção de pesquisa
Investigue o módulo BR (backup/restore) no repositório TiDB, especificamente a lógica de restauração que verifica a existência da estrutura da tabela. Examine os arquivos em `br/` ou `pkg/backup/` para entender como o processo de restauração atualmente lida com a existência da tabela após exclusão versus truncamento. O problema sugere que uma 'exclusão' deixa a estrutura da tabela enquanto 'truncamento' não, causando um comportamento de restauração diferente. O objetivo é adicionar um mecanismo de prevenção que bloqueie a restauração completa se a estrutura da tabela ainda existir. Revise os comentários existentes e quaisquer PRs relacionados (nenhum vinculado) para entender o comportamento pretendido.
Pilha de tecnologia
go
Domain
backenddatabase
Tipo Issue
Funcionalidade
DifficultyDificuldade de implementação estimada para um novo contribuidor, de 1 para alterações muito pequenas a 5 para trabalho de nível especializado.
3
Tempo estimadoUm intervalo de tempo aproximado para um colaborador experiente investigar, implementar, testar e preparar um pull request.
1-2 dias
Status da atividadeQuão disponível o issue aparece agora: novo, ativo, obsoleto, bloqueado ou aguardando entrada do mantenedor.
Ativo
ClarityCom que clareza o issue explica a mudança esperada, os critérios de aceitação e a próxima etapa.
Claro
Prerequisites
GoGit
Simpatia para novatosUma pontuação de 1 a 100 que estima o quão acessível este issue é para colaboradores iniciantes.
65