Quais são os sinais de alerta de que um contentor de base de dados foi corrompido devido a uma falha de energia?

Suspeite de corrupção quando a base de dados não consegue concluir a recuperação normal após uma falha ou apresenta inconsistências de somas de verificação, páginas, sequências de registos, tabelas ou índices.

Um encerramento não limpo não significa automaticamente que a base de dados esteja corrompida; o PostgreSQL, o MySQL, o MariaDB e outros motores semelhantes utilizam diários ou registos de escrita antecipada especificamente para recuperar o estado confirmado. O limite de alerta surge quando a recuperação se repete, o motor termina, a mesma consulta encontra páginas inválidas, as somas de verificação falham, as tabelas desaparecem, os índices contradizem os dados das tabelas ou as cópias de segurança e as verificações de integridade não conseguem ler o cluster de forma consistente.

Distinguir a Recuperação Normal Após uma Falha de um Ciclo de Recuperação

Preserve o primeiro registo de arranque após o restabelecimento da energia. Registe se o motor reproduz os registos uma vez e fica pronto, ou se reinicia repetidamente, entra em recuperação forçada ou para sempre no mesmo registo ou página.

O InnoDB pode comunicar a restauração de páginas possivelmente escritas pela metade após uma escrita interrompida; a mensagem indica que o motor está a tentar realizar uma recuperação segura após uma falha, mas falhas repetidas podem apontar para erros do InnoDB após uma interrupção de energia.

Uma única recuperação bem-sucedida, seguida de verificações normais, não prova que exista corrupção. Um ciclo, uma asserção fatal, um sinal repetido ou a incapacidade de atingir o estado pronto são sinais para parar de copiar ficheiros em bruto e testar as cópias de segurança antes que ocorram mais escritas.

Procurar Erros de Somas de Verificação e de Páginas Inválidas

Pesquise nos registos por incompatibilidade de soma de verificação, falha na verificação da página, página inválida no bloco, página corrompida, leitura incompleta, número mágico inválido ou fim de ficheiro inesperado. Registe a relação, a tabela, o bloco ou o espaço de tabelas identificado.

O pganalyze mostra a corrupção do PostgreSQL a manifestar-se como falhas de soma de verificação de páginas, seguidas de um erro de página inválida quando o bloco danificado é lido.

Não ignore o erro nem preencha as páginas danificadas com zeros antes de preservar as provas e confirmar a cobertura das cópias de segurança. O facto de o mesmo bloco falhar após vários reinícios é uma prova mais forte do que um único tempo limite da aplicação.

Observar Consultas que Falham Apenas em Determinadas Linhas ou Tabelas

Execute verificações apenas de leitura nas tabelas e consultas normalmente utilizadas pela aplicação. A corrupção pode permanecer oculta até que uma verificação, uma operação de vacuum, uma cópia de segurança ou um pedido aceda a uma página danificada.

Uma análise do PostgreSQL explica que uma incompatibilidade de soma de verificação aponta para um problema abaixo da base de dados, enquanto uma página inválida sem um aviso de soma de verificação ainda pode refletir problemas de armazenamento, memória, sistema de ficheiros ou danos acidentais nos ficheiros. O sintoma prático é uma leitura repetível de página inválida durante consultas normais.

Registe exatamente que consulta e objeto falham. Não permita que a aplicação continue a realizar escritas abrangentes enquanto apenas parte da base de dados permanece legível, pois o novo estado pode complicar a recuperação e as cópias de segurança.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verificar Inconsistências nos Índices, nas Transações e nos Metadados

Os sinais de alerta incluem chaves duplicadas que violam um índice único, linhas em falta que são acessíveis através de um caminho de acesso mas não de outro, IDs de transação inválidos, fragmentos TOAST ou de valores grandes danificados e índices que falham a validação.

A análise da Credativ sobre corrupção observa que os clusters sem somas de verificação dos dados podem revelar danos através de erros de baixo nível, como páginas inválidas, problemas de IDs de transação, inconsistências TOAST ou falhas do backend. Algumas cópias de segurança de ficheiros podem preservar páginas corrompidas sem as detetar.

Execute verificações de integridade e de índices suportadas numa cópia ou durante uma janela de manutenção controlada. A reconstrução de índices pode reparar um índice derivado danificado, mas não repara dados de tabelas corrompidos nem o armazenamento subjacente.

Correlacionar os Erros da Base de Dados com Avisos do Sistema de Ficheiros e do Armazenamento

Inspecione os registos do kernel do anfitrião, do sistema de ficheiros, do pool, da unidade, do controlador, do UPS e do ambiente de execução de contentores relativos ao período da interrupção. Procure erros de E/S, reinicializações, erros de soma de verificação, remontagens em modo só de leitura, pools degradados e ficheiros perdidos ou truncados.

Um guia de recuperação de bases de dados observa que falhas de energia e memória defeituosa podem produzir escritas de páginas corrompidas, sobretudo quando o comportamento do armazenamento não corresponde aos pressupostos de durabilidade da base de dados. Esses eventos ao nível do anfitrião ajudam a distinguir a corrupção de páginas do InnoDB de um reinício normal da aplicação.

Corrija o percurso de armazenamento antes de restaurar uma base de dados limpa nesse mesmo percurso. Uma restauração lógica bem-sucedida num suporte com falhas pode recriar o incidente ou danificar silenciosamente a substituição.

Parar as Escritas e Comprovar a Recuperação a Partir de uma Cópia de Segurança Limpa

Quando os sinais de corrupção são repetíveis, pare as aplicações dependentes, crie um instantâneo ou clone o volume afetado, se for seguro, e preserve os registos e a configuração. Teste a cópia de segurança mais recente num armazenamento separado antes de modificar o cluster original.

A lista de verificação da ZimaSpace para fazer cópias de segurança do estado das aplicações Docker define o que deve existir antes de uma tentativa destrutiva de recuperação da base de dados.

O sistema só é fiável quando a base de dados restaurada arranca sem problemas, as verificações de integridade são aprovadas, as consultas e escritas representativas são bem-sucedidas, as cópias de segurança são concluídas e o armazenamento do anfitrião não comunica novos erros. Os modos de recuperação forçada devem ser utilizados para salvamento ao abrigo de um plano de recuperação documentado, e não como operação normal.