Recuperação do 'cabeçalho de página inválida' do Postgresql

3

Atualmente, estou trabalhando com um sistema embarcado que usa o Postgresql para armazenamento de dados. Atualmente, temos um problema em que as caixas às vezes são reiniciadas sem aviso e sem desligamento adequado. Isso obviamente nos deixa com problemas de banco de dados em alguns casos (cabeçalho de página inválido em certas tabelas de alto tráfego é o sintoma mais comum).

O que eu quero saber é, qual é a maneira mais fácil de limpar os erros? Obviamente, vou perder dados, mas como os erros geralmente ocorrem em tabelas que contêm dados efêmeros, não me importo, só quero colocar o sistema de volta em operação.

Neste momento, nosso procedimento é eliminar e recriar quaisquer tabelas afetadas. Existe algo mais que poderíamos fazer que seria mais rápido? Como eu disse, estou bem com a perda de dados na página afetada, só quero que a coisa esteja funcionando.

Plataforma é Ubuntu 7.04, Postgresql 8.2 (Não podemos forçar uma atualização para o cliente agora). O sistema de arquivos é ext3, em um cartão CF de 2 GB.

Obviamente, corrigir as reinicializações inesperadas é minha maior prioridade, mas o progresso é lento (é difícil reproduzir no laboratório). Enquanto isso, espero por uma solução mais simples que permita às pessoas de campo lidar mais rapidamente com os problemas que surgem.

    
por Michael Kohne 13.05.2009 / 17:05

2 respostas

0

Você já tentou definir o método de sincronização do WAL para fsync_writethrough ?

    
por 13.05.2009 / 17:51
1

Só quero acompanhar o bandaiding, caso alguém precise:

Você pode ativar zero_damaged_pages e executar um VACCUUM na tabela afetada, isso deve limpar todas as páginas que contenham dados de defeito conhecidos. Isto não irá protegê-lo da corrupção silenciosa dos valores das colunas, já que o PostgreSQL não faz nenhum checksum em nível de bloco / página de seus dados a partir de agora.

Portanto, esta é uma opção de último recurso, a fixação da origem dos problemas é sempre preferível;).

    
por 30.05.2009 / 02:36

Tags