Tengo un servidor en vivo y un cuadro de desarrollo, los llamo live y dev respectivamente, ambos ejecutan postgresql. Puedo ver ambos y administrarlos con pgadmin4 sin problemas, y ambos son completamente funcionales, uno detrás de un sitio web en vivo y el otro cuando ejecuto un sitio web en modo de depuración en mi cuadro de desarrollo. Configuración bastante ordinaria.
Durante años, he estado ejecutando el mismo script de bash que escribí que volca la base de datos en vivo y luego la restaura en el cuadro de desarrollo, así que tengo la última instantánea en vivo para trabajar.
Hoy esto me falla con el mensaje titulado:
pg_restore: [archiver] unsupported version (1.14) in file headerTraté de diagnosticar esto y busqué extensamente en línea, pero estoy atormentado y he fallado, así que aquí tengo un tope para la experiencia.
Para ayudar compartiré lo siguiente:
$ 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 pg_dump y pg_restore son versiones idénticas y:
$ 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
Puedo ver que no son solo versiones idénticas, sino que se ejecutan con el mismo script de contenedor (que resulta ser un script perl, ahora ese es un lenguaje que ya no se ve mucho y solía codificar ampliamente)
Así que me quedo totalmente perplejo. Pensando que puede haber un problema de versión con la máquina en vivo:
$ 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)
Puedo ver que el cuadro en vivo tiene una versión un poco más antigua de pg_dump (lo que solo importaría si pg_dump en mi cuadro de desarrollo de alguna manera usara un RPC en el cuadro en vivo para ejecutar su pg_dump).
Ahora, tal vez haya una pequeña pista en el hecho de que mi caja de desarrollo ha visto algunas actualizaciones postgresql, por ejemplo:
$ 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
Los grupos 11 y 12 permanecen sin usar, como lo demuestran los archivos de registro vacíos. Estoy usando 10. Pero me doy cuenta de 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)
lo cual es ligeramente sospechoso, pero nuevamente no es obviamente una causa o relacionada:
- Estoy usando pg_dump no psql
- Estoy usando solo las herramientas pg de los cuadros de desarrollo, no las cajas vivas (deberían ser irrelevantes, la transferencia de datos completa teóricamente a través del puerto 5432 en el cuadro en vivo que entrega un volcado de databse a pg_dump en mi cuadro de desarrollo.
Aquí están los grupos en la caja de amor y está sobre el puerto 5432 que en live.lan estoy ejecutando 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
Estoy profundamente perplejo y aturdido en este momento por esto. Apreciaría profundamente las pistas que avanzan. Si me veo obligado a pescar en la oscuridad, probablemente desinstalaré postgres 11 y 12 nuevamente y veré si eso ayuda, de lo contrario terminaré teniendo que rastrear /usr/share/postgresql-common/pg_wrapperpara ver cómo y dónde las dos rutas de pg_dump y pg_restore divergen por rutas de versiones incompatibles .
Actualizar:
Otra pista que he descubierto, que me permite una solución alternativa, pero que simplemente profundiza el misterio, es la siguiente:
$ 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)
Eso es desconcertante más allá de la creencia. Las únicas explicaciones posibles:
- a pesar de informar números de versión idénticos, los dos pg_dumps son diferentes. Yo descartaría esto como algo increíble.
- pg_dump ejecuta pg_wrapper que ejecuta / usr / lib / postgresql / 10 / bin / pg_dump con algunos argumentos misteriosos que lo rompen.
El segundo es plausible y requerirá que instrumente pg_wrapper para diagnosticar.
Actualización 2:
Y una instrumentación de pg_wrapper más tarde. Eventualmente, pg_dump ejecuta pg_wrapper que se ejecuta /usr/lib/postgresql/12/bin/pg_dumppero se ejecuta /usr/lib/postgresql/10/bin/pg_restore... ¡Vaya! ¡Empezando a pensar que esto es un error de interoperabilidad de la versión postgresql!
Actualización 3:
Mirando más profundamente pg_wrapper, clavó la causa, y sí, diría que es un error de tipo pg_wrapper, aunque puede ser discutible, aunque en mi humilde opinión. Esto es lo que hace:
Si --hostse proporciona, entonces utiliza la versión más reciente de postgresql instalada (12 en mi caso y esto es para pg_dump, por lo que pg_dump 12 crea el volcado)
Si --hostno se proporciona, consulta la configuración del usuario (10 en mi caso, y esto es para pg_restore, por lo que se ejecuta pg_restore 10 y no puede leer un archivo creado por pg_dump 12).
Entonces, ¿por qué es esto un error? Porque tengo una configuración de uso y me gustaría que se respete si estoy hablando con un host remoto o no. Más aún, si especifico un host, ciertamente no espero usar la última versión local ignorando la configuración local. Esperaría respetar la configuración local (como es el caso cuando no se especifica un host remoto) o intentar hacer coincidir la versión de rmeote hosts. Apoyarse arbitrariamente en la última versión instalada es, en mi humilde opinión, profundamente cuestionable.
PERO resulta que hay una solución alternativa que funciona. Esencialmente en lugar de:
sudo -u postgres pg_restore -l test.backupesto funciona:
sudo -u postgres pg_restore --host=localhost -l test.backupAl especificar irónicamente el host, lo forzamos a ignorar las configuraciones locales y usar la versión más reciente de pg_restore, que parece funcionar bien restaurando a un clúster 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.psqlpero eso no funcionó. También recibo el mismo error al importar una base de datos.
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.