Início / server / Perguntas / 713700
Accepted
muffel
Asked: 2015-08-13 10:35:28 +0800 CST

postgresql: mensagem 'cabeçalho de página inválido' mesmo após soltar e recriar

  • 772

Meu servidor Ubuntu 14.04 LTS executando o postgresql 8.4.11 travou e, após uma reinicialização, o servidor de aplicativos executando uma consulta no postgresql relatou o seguinte erro

ERROR: invalid page header in block 40 of relation base/18038/22194

Pesquisei no Google, tentei criar um despejo e usei a mensagem de erro resultante para identificar uma tabela quebrada. eu então executei

SET zero_damaged_pages = on;
VACUUM FULL damaged_table;
-- vacuum didn't report any errors here
REINDEX TABLE damaged_table;

outros mencionaram reindexdb, então eu corri

$ reindexdb -s mydb

também, mas o problema continuou o mesmo.

Finalmente - obtive um backup funcional do banco de dados - soltei e recriei todo o banco de dados

DROP DATABASE mydb;
CREATE DATABASE mydb;

e restaurou o backup:

cat mydump| sudo -u postgres pgsql mydb

Mas mesmo agora o problema continua o mesmo. Não sei muito sobre postgresql, mas como esse erro pode sobreviver a uma recriação do banco de dados? Infelizmente, preciso fazer o banco de dados funcionar na mesma máquina novamente.

Há mais alguma coisa que eu possa tentar para que o banco de dados funcione novamente?

linux

2 respostas

  1. Best Answer

    Parece que você tem algum tipo de corrupção em seu sistema de arquivos ou disco.

    Eu recomendo procurar aqui: corrupção do postgresql

    Depois disso, eu procuraria dmesgqualquer /var/log/messageserro de hardware que você pudesse ver.

    Se você obtiver um despejo de trabalho, eu copiaria o diretório de dados atual de /var/lib/postgresql/8.4/main, executaria pg_createcluster 8.4 mainem um novo diretório e tentaria restaurar lá e ver se isso ajuda a corrigir quaisquer problemas remanescentes.

    Se você ainda estiver tendo problemas depois disso, entrar #postgresqlno Freenode IRC, ou [email protected]seria meu próximo passo, se eu tivesse que colocar isso em funcionamento o mais rápido possível.

    Espero que ajude. Boa sorte. =)

    • 3

  2. Se você tiver um escravo, defina hot_standby_feedback- 'on'o, se ainda não o tiver. Faça pg_dump e escreva-o em /dev/null para não consumir espaço.

    nohup pg_dump db_name -v -Fc -f /dev/null &

    Se o despejo for bem-sucedido, seu escravo está bem. Faça um failover. Não haverá perda de dados.

    Outra maneira de validar seu escravo é fazer:

    explain select count(*) from table_name;

    Se for bem-sucedido e estiver usando uma varredura de sequência, seu escravo está bom. Você pode não ter que considerar esta opção se estiver usando a varredura de índice.

    Observação: isso funciona apenas se seu mestre for afetado por corrupção no nível de armazenamento.

    Aconteceu que enfrentei o mesmo problema hoje e consegui corrigi-lo.

    • 2

relate perguntas