Quais são as práticas que você segue para evitar atualizações incorretas de dados em grandes bancos de dados?


20

Um conselho típico antes de qualquer implantação de produção é fazer backup do banco de dados primeiro. Dessa forma, se a nova atualização apresentar algum problema que possa levar à perda potencial de dados ou à corrupção de dados lógicos, você ainda terá um backup para comparar e corrigir registros antigos.

No entanto, isso pode funcionar bem até o tamanho do banco de dados estar em poucos GBs. Quando o tamanho do banco de dados é enorme, os backups demoram muito tempo para serem concluídos. Quais são algumas das práticas recomendadas que devem ser seguidas nessas situações, para evitar corrupção de dados lógicos devido a problemas lógicos em uma implantação de código?


11
Os backups não são apenas para quando você faz implantações. Quero dizer, sua perda de dados está a apenas uma falha de disco, e essas são imprevisíveis e podem acontecer hoje ou amanhã. (Matrizes de ataque não são a resposta, elas também travam.) #
Pieter B

10
Eu reformularia essa pergunta, o problema não é que os backups demoram muito, o problema é que, no caso de uma atualização ter uma falha desastrosa, uma restauração pode ser necessária, o que pode bloquear a produção por um longo tempo. Então, o que você realmente procura é uma estratégia para mitigar os riscos de uma falha durante uma atualização.
Doc Brown

1
Eu concordo com @DocBrown aqui. Evitar a corrupção de dados e os backups que demoram muito são realmente duas perguntas separadas.
Robbie Dee

1
Quando você aceita rapidamente, não recebe tanta informação.
Paparazzo

1
O que você quer dizer com "problemas lógicos em uma implantação de código"?
Paparazzo

Respostas:


25

Como alguém que lida regularmente com a atualização do banco de dados de produção para clientes para nossas atualizações de software, digo que a melhor maneira de minimizar erros é fazer as atualizações o mais simples possível.

Se você pode executar uma alteração em todos os registros, em vez de registros específicos, é preferível.

Em outras palavras, se você receber uma lista de IDs de registros que precisam de seu estado alterado, você deve se perguntar por que a atualização está sendo feita no contexto do programa. Pode ser que, dos 10 registros que você precise atualizar, a tabela tenha apenas 10 elementos. Portanto, você deve se perguntar se, conceitualmente, tudo o que está fazendo é atualizar o estado de todos os registros.

Se você pode inserir, é preferível.

O ato de adicionar um registro é independente. Com isso, quero dizer que há apenas um efeito colateral da adição de um registro, e essa é a existência de um registro que não existia antes. Portanto, a menos que você esteja adicionando um registro que não deveria estar lá, não deve haver problemas.

Se você pode evitar a exclusão, é preferível.

Se você estiver executando uma exclusão, está removendo dados que seriam irrecuperáveis ​​sem um backup. Se possível, tente organizar os dados de forma que você possa desativar os registros alterando seu estado em vez de excluir fisicamente o registro. O excesso de dados pode ser colocado em uma partição ou removido totalmente em um momento posterior, quando você tiver certeza de que não há problemas.

Tenha uma política de atualização consistente.

Se você precisar atualizar um registro, uma das várias coisas pode acontecer:

  1. Seu registro não existe.
  2. Seu registro existe, mas já foi alterado.
  3. Seu registro existe e requer a alteração.

Você precisa ter uma política para determinar o curso da ação, caso algo não ocorra conforme o planejado. Por uma questão de simplicidade, você deve ser consistente em todos os aspectos e aplicar esta política em qualquer situação desse tipo, não apenas em tabelas específicas. Isso facilita a recuperação de dados posteriormente. Geralmente, minha política é escrever o script de forma a poder executá-lo mais tarde. Se o script falhar, é bom saber que você pode fazer os ajustes adequados e executar novamente, no entanto, você pode escolher sua própria política que melhor lhe convier.

Backups

Isso de forma alguma o dispensa de executar um backup antes de executar qualquer atualização em um ambiente de produção! Embora, mesmo com um backup, considero uma falha ter que usá-lo. Perder dados não pode ser uma possibilidade, mesmo no pior cenário.

Conclusão

Você nem sempre será capaz de fazer do seu jeito. O esquema da tabela provavelmente não será determinado por você e, como tal, significa que os tipos de atualizações que você espera executar serão complicados e arriscados. Embora, se você tiver alguma opinião a fazer, ajude a manter esses pontos em mente, pois eles fazem atualizações diretas e sem riscos significativos.

Boa sorte!


Concordo com tudo o que você disse, mas fiquei curioso com o que você pensa sobre transações, quando há 10 registros que precisam mudar de 10k e inserções / atualizações de todos os registros não são viáveis?
Estou aqui para chapéus de inverno

Então você acabou de atualizar os 10 registros. Eu disse que se puder, faça. Eu não disse, mesmo que destrua o banco de dados de produção do seu cliente. Siga meu conselho com um grão de sal, por favor.
Neil

12

Nesse ponto, você deve usar um sistema de banco de dados de nível comercial que suporte instantâneos (o Oracles chama de Flashback ) - esse é exatamente o tipo de coisa para a qual eles servem.

Lembre-se de que você precisa de um conceito de backup de qualquer maneira - ter mais dados não significa que você descarta os backups porque eles se tornam difíceis, pelo contrário. Você precisa de algum tipo de backup contínuo, por exemplo, com base na replicação com failover automático.


Não estou dizendo que quero descartar backups. Os backups agendados estão sempre lá. A questão é mais sobre backups ad-hoc, que não são um problema para sistemas pequenos.
Pritam Barhate

Para aprofundar, essa linha de pensamento veio do NoSQL DB como plataformas de serviço. Na verdade, estava lendo a documentação do Firestore, quando apareceu. Se você precisar de backups logicamente consistentes externos, isso parecerá muito caro. Por isso, fiquei imaginando como as equipes de produtos de sucesso trabalham com esses sistemas e como garantem que a corrupção de dados lógicos não ocorra.
Pritam Barhate

@PritamBarhate: você não precisa de "mais backups" por causa de atualizações. Em um banco de dados de produção em que as pessoas trabalham com esses dados, os backups precisam ser feitos pelo menos diariamente, com ou sem atualizações. Restaurações são o seu problema, você deseja evitar restaurações desnecessárias em todas as circunstâncias.
Doc Brown

3
A replicação com failover automático é redundância não é mais uma estratégia de backup para bancos de dados do que o uso de RAID para discos .
Blrfl

1
Todos os pontos positivos sobre backups e capturas instantâneas, mas limpar uma operação de banco de dados danificada (se várias horas de novos dados foram adicionados antes de serem realizados) pode ser muito difícil, dependendo do cenário e dos outros sistemas que ele afeta (planejadores, outras entradas do banco de dados que dependem dele, se abranger várias tabelas, caches, autenticação, etc). Eu sempre presumo que vou precisar usar um backup, mas sempre pelo menos tento nunca precisar.
Anonymous Penguin

3

Esta é uma área massiva - portanto, espere que esta questão seja encerrada em um prazo relativamente curto, mas, em primeiro lugar, como ex-DBA em bancos de dados yuge:

Mart / Repositório

Você pode reduzir alguns riscos se tiver um banco de dados separado para atualizações e um banco de dados separado que todos usem. Depois, é apenas um caso de copiar os dados de um banco de dados para o outro após várias verificações. Mart / repository é como às vezes é descrito, mas você pode ter primário / secundário, mestre / escravo etc.

Código fonte

Para tudo o que pode mudar, tenha um código-fonte relacionado à forma como os dados foram atualizados. Quantos deles você varia de banco de dados para banco de dados, mas você pode ter um para cada usuário, função, feed de dados, módulo de código etc.

Criar / atualizar data

Algo que pode ajudar bastante ao rastrear onde as coisas deram errado está em criar e atualizar dados para cada linha. Então você pode ver rapidamente quais linhas foram atualizadas.

ETL

Se a atualização do banco de dados fizer parte de um data factory, você poderá restaurar um vintage anterior a partir de arquivos simples.

Cópia de segurança

É claro que os backups completos ocupam muito espaço, mas o cenário usual é que um backup completo ocorra em intervalos regulares (digamos, semanalmente) e parciais com mais frequência (diariamente etc).

Recuperação pontual

Dependendo do RDBMS que você está usando, algum suporte indica a recuperação do tempo. Isso permite reverter para a época em que um bom estado era conhecido. No entanto, isso requer uma grande quantidade de armazenamento, o que aumenta para o quanto você deseja voltar.

Auditar

Ter tabelas de auditoria informará quem (ou o que) fez uma atualização em uma linha. Isso pode lhe dar um bom ponto de partida para a investigação.

História

Para algumas tabelas críticas, uma cópia da linha pertinente é tirada no momento da atualização para que os dados possam ser restaurados, se necessário.

Data de validade

Certifique-se de que sejam realizadas verificações básicas de validação nos dados antes de serem armazenados - além das verificações básicas do tipo de dados.

Integridade referencial

A integridade referencial não é uma bala de prata, mas pode ajudar a garantir que os dados estejam bem estruturados.



2

Muitas vezes, se estamos fazendo uma atualização "one shot", fazemos um backup da produção e a restauramos em um servidor de teste. Em seguida, criamos um conjunto de testes e executamos a única tentativa. Verificamos que os dados foram alterados pelos testes e ficamos à vontade para que a atualização seja bem-sucedida e modifique os dados da maneira que esperamos. Isso é chamado de execução a seco ou experimental. Eu recomendo fazer isso.

Isso dá a todos uma boa sensação de que o único tiro será bem-sucedido. Não podemos garantir 100%, porque os dados serão atualizados a partir da data do teste, mas aumentamos os fatores de confiança e sucesso. Isso também dá uma idéia real de quaisquer problemas que ocorrerão, pois estamos usando uma cópia da produção. Agora, se por algum motivo a atualização falhar, sempre podemos voltar para a execução posterior antes da restauração, se necessário, mas deveríamos ter encontrado e corrigido quaisquer problemas com a execução a seco.

Se você não pode obter o banco de dados inteiro (se realmente grande), tente exportar um tamanho de amostra menor e execute a atualização (pequena execução a seco) nos dados reais. Prefiro todo o conjunto de dados, se possível, para garantir que o teste seja o mais completo possível.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.