pg_restore: [archiver] versão não suportada (1.14) no cabeçalho do arquivo


8

Eu tenho um servidor ativo e uma caixa de desenvolvimento, chame-os de vivo e dev, respectivamente, ambos executando o postgresql. Eu posso ver os dois e gerenciar ambos com o pgadmin4 sem problemas, e ambos são totalmente funcionais: um atrás de um site ativo e o outro quando eu corro por site no modo de depuração na minha caixa de desenvolvimento. Configuração bastante comum.

Por anos, eu tenho executado o mesmo script bash que escrevi que despeja o banco de dados ao vivo e depois o restaura na caixa de desenvolvimento, para que eu tenha o último instantâneo ao vivo para trabalhar.

Hoje isso me falha com a mensagem intitulada:

pg_restore: [archiver] unsupported version (1.14) in file header

Eu tentei diagnosticar isso e procurei extensivamente on-line, mas estou atormentado e falhei, então aqui estou eu na mão para obter conhecimento.

Para ajudar, compartilharei o seguinte:

$ pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ pg_restore --version
pg_restore (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test.backup
$ ls -l test.backup 
-rw-r--r-- 1 bernd bernd 2398358 Dec 23 23:40 test.backup
$ file test.backup 
test.backup: PostgreSQL custom database dump - v1.14-0
$ pg_restore --dbname=mydb test.backup 
pg_restore: [archiver] unsupported version (1.14) in file header

Dado que pg_dump e pg_restore são versões idênticas e:

$ which pg_dump
/usr/bin/pg_dump
$ which pg_restore
/usr/bin/pg_restore
$ ls -l /usr/bin/pg_dump /usr/bin/pg_restore
lrwxrwxrwx 1 root root 37 Nov 14 23:23 /usr/bin/pg_dump -> ../share/postgresql-common/pg_wrapper
lrwxrwxrwx 1 root root 37 Nov 14 23:23 /usr/bin/pg_restore -> ../share/postgresql-common/pg_wrapper

Eu posso ver que elas não são apenas versões idênticas, mas são executadas pelo mesmo script wrapper (que por acaso é um script perl - agora é uma linguagem que você não vê muito e eu costumava codificar extensivamente)

Então, eu fico totalmente perplexo. Pensando que pode haver um problema de versão na máquina ativa:

$ ssh live.lan
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64)
$ which pg_dump
/usr/bin/pg_dump
$ which pg_restore
/usr/bin/pg_restore
$ pg_dump --version
pg_dump (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)
$ pg_restore --version
pg_restore (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)

Eu posso ver que a caixa ao vivo tem uma versão um pouco mais antiga do pg_dump (o que seria importante se o pg_dump na minha caixa de desenvolvimento de alguma forma usasse um RPC na caixa ao vivo para executar seu pg_dump).

Agora, talvez haja uma pequena pista no fato de que minha caixa de desenvolvimento já viu algumas atualizações do postgresql, e por exemplo:

$ pg_lsclusters
Ver Cluster Port Status Owner    Data directory              Log file
10  main    5432 online postgres /var/lib/postgresql/10/main /var/log/postgresql/postgresql-10-main.log
11  main    5433 online postgres /var/lib/postgresql/11/main /var/log/postgresql/postgresql-11-main.log
12  main    5434 online postgres /var/lib/postgresql/12/main /var/log/postgresql/postgresql-12-main.log

Os 11 e 12 clusters permanecem sem uso, conforme evidenciado por arquivos de log vazios. Estou usando 10. Mas noto que:

$ psql --version
psql (PostgreSQL) 12.1 (Ubuntu 12.1-1.pgdg18.04+1)
$ ssh live.lan
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64)
$ psql --version
psql (PostgreSQL) 10.10 (Ubuntu 10.10-0ubuntu0.18.04.1)

que é levemente suspeito, mas novamente não é obviamente uma causa ou relação:

  1. Estou usando pg_dump não psql
  2. Estou usando apenas as ferramentas dev box pg e não as caixas ativas (elas devem ser irrelevantes, todos os dados são transferidos teoricamente pela porta 5432 na caixa ativa, que fornece um dump de dados para pg_dump na minha caixa dev.

Aqui estão os clusters na caixa do amor e está na porta 5432 que no live.lan estou executando o pg_dump!

$ pg_lsclusters 
Ver Cluster Port Status Owner    Data directory           Log file
10  main    5432 online postgres /data/postgresql/10/main /var/log/postgresql/postgresql-10-main.log

No momento, estou profundamente perplexo e confuso. Apreciaria profundamente pistas para a frente. Se eu sou obrigado a pescar no escuro, provavelmente desinstalarei o postgres 11 e 12 novamente e verei se isso ajuda. Caso contrário, acabarei tendo que rastrear /usr/share/postgresql-common/pg_wrapperpara ver como e onde os dois caminhos de pg_dump e pg_restore divergem nos caminhos incompatíveis da versão .

Atualizar:

Outra pista que descobri, que me permite uma solução alternativa, mas simplesmente aprofunda o mistério é a seguinte:

$ sudo -u postgres pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test.backup
$ sudo -u postgres /usr/lib/postgresql/10/bin/pg_dump --host=live.lan --port=5432 --dbname=mydb --username=myuser --format=custom > test2.backup
$ sudo -u postgres pg_restore -l test.backup
pg_restore: [archiver] unsupported version (1.14) in file header
$ sudo -u postgres pg_restore -l test.backup
... produces listing of contents ...
$ sudo -u postgres pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)
$ sudo -u postgres /usr/lib/postgresql/10/bin/pg_dump --version
pg_dump (PostgreSQL) 10.11 (Ubuntu 10.11-1.pgdg18.04+1)

Isso é desconcertante além da crença. As únicas explicações possíveis:

  1. apesar de relatar números de versão idênticos, os dois pg_dumps são diferentes. Eu descartaria isso como algo além da crença.
  2. O pg_dump executa o pg_wrapper que executa / usr / lib / postgresql / 10 / bin / pg_dump com alguns argumentos misteriosos que o quebram!

O segundo é plausível e exigirá que eu instrua o pg_wrapper para diagnosticar.

Atualização 2:

E uma instrumentação de pg_wrapper mais tarde. Ele conclui que o pg_dump executa o pg_wrapper, que /usr/lib/postgresql/12/bin/pg_dumpainda funciona /usr/lib/postgresql/10/bin/pg_restore... Vá em frente! Começando a pensar que isso é um bug de interoperabilidade da versão postgresql!

Atualização 3:

Olhando mais fundo pg_wrapper, acertando a causa, e sim, eu diria que é um bug do tipo pg_wrapper, embora possa ser discutível, apesar de IMHO. Aqui está o que ele faz:

E se --host for fornecido, ele usa a versão mais recente do postgresql instalada (12 no meu caso e isso é para pg_dump, portanto, pg_dump 12 cria o dump)

Se --hostnão for fornecido, ele consultará a configuração do usuário (10 no meu caso, e isso é para pg_restore, portanto, o pg_restore 10 é executado e não pode ler um arquivo criado por pg_dump 12).

Então, por que isso é um bug? Porque eu tenho uma configuração de uso e gostaria que fosse respeitado se estou falando ou não com um host remoto. Mais especificamente, se eu especificar um host, certamente não espero usar a versão local mais recente, ignorando a configuração local. Eu esperaria respeitar a configuração local (como é o caso quando nenhum host remoto for especificado) ou tentar corresponder à versão dos hosts rmeote. Inclinar-se arbitrariamente na versão mais recente instalada é IMHO profundamente questionável.

Mas acontece que existe uma solução alternativa que funciona. Essencialmente, em vez de:

sudo -u postgres pg_restore -l test.backup

isso funciona:

sudo -u postgres pg_restore --host=localhost -l test.backup

Ao especificar o host ironicamente, forçamos que ele ignore as configurações locais e use a versão mais recente do pg_restore, que parece funcionar perfeitamente na restauração de um cluster PG 10.


"Começando a pensar que isso é um bug de interoperabilidade da versão postgresql!" Parece mais um bug de embalagem.
jjanes

1
Provavelmente uma pergunta para dba.stackexchange.com , também evite postar lá E aqui, pois alguns usuários estão ativos em ambos.
Christophe Roussy

Legal. Existe uma maneira de migrar perguntas entre sites de SO. Não tenho certeza de como está fora de mão. Mas admito que publiquei aqui, porque aqui é onde encontrei perguntas semelhantes (mesmo sintoma, versões diferentes, mas sem soluções que funcionassem para mim).
Bernd Wechner

@BerndWechner Eu usei o seguinte comando: sudo -u postgres pg_restore --verbose --clean --jobs=4 --disable-triggers --no-acl --no-owner -h localhost -U postgresql -d everest_development dump.psqlmas isso não funcionou. Também estou recebendo o mesmo erro ao importar um banco de dados.
LearningROR

Além disso, se eu fizer:muhammad@muhammad-mohsin:~/workspace_ror/everest$ psql -d everest_development -f dump.psql The input is a PostgreSQL custom-format dump. Use the pg_restore command-line client to restore this dump to a database.
LearningROR

Respostas:


1

Aqui está outra reviravolta, mas observe primeiro que este é um caso do Windows. Se for apenas linux para você, não leia mais. Todos os conselhos dados aqui não me ajudaram; eventualmente, a causa IMC era mais simples e tinha a ver com o uso do pgAdmin. Devido ao problema repetitivo das versões mais recentes, meu hábito é instalar o pgAdmin separadamente (não usando o stackbuilder). (PELO MENOS), nesse caso, o pgAdmin possui seu próprio cache de programas utilitários e os utilizará, a menos que você o diga de maneira diferente. Minhas instâncias pg ainda são a versão 11 (.6), mas as últimas pgAdmin provavelmente terão utilitários V12. O que pode muito bem causar uma discrepância de versão. Isso me ocorreu depois de fazer várias transferências bem-sucedidas da minha máquina principal para um laptop. Portanto, no pgAdmin do (menu) Arquivo-> preferências-> Caminhos e defina Caminhos Binários correspondentes à sua instalação do postgres, C IMC: \ Arquivos de programas \ PostgreSQL \ 11 \ bin. Isso fez o trabalho.


1

verifique e verifique se o seu pgadmin está atualizado, eu tive esse problema e o resolvi atualizando-o


0

Esse erro é causado por uma incompatibilidade de versão entre a versão do pg_dump usada para criar o arquivo de backup e a versão do pg_restore usada para tentar a restauração.

A atualização do meu PostgreSQL resolveu o problema


Para qual versão? A v12 claramente teve esse problema no pg_wrapper. Para qual versão você atualizou? Se houver uma atualização para 12 que a conserte, informe-nos.
Bernd Wechner

Eu atualizei para a versão 12.2
Wariored
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.