Início / dba / Perguntas / 22486
Accepted
ThinkingMonkey
Asked: 2012-08-15 04:12:48 +0800 CST

Iniciar o servidor PostgreSQL após uma falha no HDD resulta em FAILED STATE

  • 772

estou usando Fedora 15com PostgreSQL 9.1.4. O Fedora travou recentemente após o que:

Uma tentativa de iniciar o servidor PostgreSQL:

service postgresql-9.1 start

dá

Starting postgresql-9.1 (via systemctl):  Job failed. See system logs and 'systemctl status' for details.
                                                       [FAILED]

Embora, o servidor inicie normalmente quando eu inicio o servidor pela primeira vez após a reinicialização do sistema .
Mas, uma tentativa de usar psqldá este erro:

psql: could not connect to server: No such file or directory
    Is the server running locally and accepting
    connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

.s.PGSQL.5432arquivo não está presente em nenhum lugar do sistema. A locate .s.PGSQL.5432não produz nada.

O log do sistema tem isso:

Aug 14 17:31:58 localhost systemd[1]: postgresql-9.1.service: control process exited, code=exited status=1
Aug 14 17:31:58 localhost systemd[1]: Unit postgresql-9.1.service entered failed state.

UMA

systemctl status postgresql-9.1.service

dá

postgresql-9.1.service - SYSV: PostgreSQL database server.
          Loaded: loaded (/etc/rc.d/init.d/postgresql-9.1)
      Active: failed since Tue, 14 Aug 2012 17:31:58 +0530; 58s ago
     Process: 2811 ExecStop=/etc/rc.d/init.d/postgresql-9.1 stop (code=exited, status=1/FAILURE)
     Process: 12423 ExecStart=/etc/rc.d/init.d/postgresql-9.1 start (code=exited, status=1/FAILURE)
    Main PID: 2551 (code=exited, status=1/FAILURE)
      CGroup: name=systemd:/system/postgresql-9.1.service

Eu não alterei a configuração padrão do fsync, então acho que foi definido como on. Estou em um HDD. O HDD travou.

Falha no disco rígido

A falha do HDD resultou na execução de um manual fsckem um prompt e não baseado em GUI. Com ele consertando zilhões de inodes, etc. Depois disso, reiniciei o sistema com um Ctrl++ Alt.Delete

O log do PostgreSQL tem isto:

LOG:  database system was interrupted; last known up at 2012-08-14 17:31:57 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/41A4E58
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13016) exited with exit code 1
LOG:  aborting startup due to startup process failure

Atualizar

Tentar iniciar o servidor depois de fazer uma cópia do /var/lib/pgsqldiretório no nível do sistema de arquivos e executar ./pg_resetxlog -f /var/lib/pgsql/9.1/data/com o resultado xlog -f /var/lib/pgsql/9.1/data/ainda produz:

LOG:  database system was interrupted; last known up at 2012-08-14 18:46:36 IST
LOG:  database system was not properly shut down; automatic recovery in progress
LOG:  record with zero length at 0/6000078
LOG:  redo is not required
FATAL:  could not access status of transaction 1
DETAIL:  Could not open file "pg_multixact/offsets/0000": No such file or directory.
LOG:  startup process (PID 13766) exited with exit code 1
LOG:  aborting startup due to startup process failure
postgresql linux

1 respostas

  1. Best Answer

    A resposta real estará nos logs do PostgreSQL, em /var/lib/pgsql/data/pg_log.

    No entanto, antes de tomar qualquer ação: É vital que você faça uma cópia de seu banco de dados no nível do sistema de arquivos antes de tentar reparar se algum de seus dados for valioso para você . Veja http://wiki.postgresql.org/wiki/Corruption . Você deve copiar todo o diretório de dados. No Fedora, isso é /var/lib/pgsql/datapadrão, mas verifique se está correto para sua instalação.

    Com base nos logs que você postou, certamente há algum grau de corrupção do banco de dados. O armazenamento em que o banco de dados está (o disco rígido ou o sistema de arquivos) provavelmente está danificado. Faça uma cópia AGORA e coloque-a em um disco rígido ou sistema diferente .

    Apenas depois de fazer uma cópia completa do nível do sistema de arquivos do seu diretório de dados, tente usar pg_resetxlog para limpar os logs de transação danificados e iniciar seu banco de dados. Mesmo que comece, é altamente provável que esteja corrompido; você deve pg_dumprefazer initdbe restaurar o despejo para a nova instância.

    Se você ainda não conseguir iniciá-lo após um pg_resetxlog, poste um log atualizado da tentativa de inicialização após resetxlog. É possível que você precise iniciar o Pg no modo autônomo com:

    sudo -u postgres postgres --single -D /var/lib/pgsql/data -P -f i postgres

    Se isso funcionar, dando-lhe um backend>prompt, tente novamente depois de substituir o último "postgres" pelo nome do banco de dados ao qual deseja se conectar. Você deve ser capaz de SELECT, COPYdados de tabelas, etc.

    Se isso não funcionar, ou seja, você não pode iniciar um back-end autônomo, provavelmente é hora de restaurar a partir de backups - desde que você seja sensato o suficiente para tê-los. Se alguém lendo isto estiver na mesma posição, entre em contato com um consultor PostgreSQL experiente para ver se eles podem recuperar dados de seu banco de dados. Esteja preparado para pagar por seu tempo e experiência.

    Seu sistema de arquivos provavelmente está danificado

    A gravidade do dano à instalação do PostgreSQL sugere que todo o seu sistema de arquivos provavelmente está danificado. Você pode querer considerar restaurar todo o sistema a partir de um backup ou reinstalá-lo.

    Eu não confiaria neste sistema de arquivos, fsckou não fsck.

    Teste SMART sua unidade

    Eu também recomendo que você execute uma SMARTverificação em seu disco rígido com smartctlsmartmontools; supondo que seja /dev/hdaisso smartctl -d ata -a /dev/sda | less. Procure um teste de integridade com falha uncorrectable_sectors, uma taxa de erro de leitura alta, um reallocated_sector_count maior que 2 ou 3 ou um current_pending_sector diferente de zero. Execute smartctl -d ata -t long /dev/sdapara executar um autoteste não destrutivo em seu HDD; não interromperá o funcionamento normal do sistema. Quando o tempo estimado tiver decorrido, execute smartctl -d ata /dev/sdanovamente e observe o log de autoteste para ver se ele passou.

    Se algo parecer menos do que perfeito, substitua a unidade.

    No futuro, considere automatizar esse teste por meio smartdde aviso antecipado de falhas no drive.

    (O conteúdo desta postagem ficou obsoleto devido às atualizações da pergunta. Se você estiver solucionando um problema semelhante, consulte o histórico de edições desta resposta).

    • 15

relate perguntas