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 headerEu 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 headerDado 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_wrapperEu 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.logOs 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:
- Estou usando pg_dump não psql
- 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.logNo 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:
- 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.
- 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.backupisso funciona:
sudo -u postgres pg_restore --host=localhost -l test.backupAo 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.
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.
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.