pg_restore: [архиватор] неподдерживаемая версия (1.14) в заголовке файла

У меня есть живой сервер и окно разработки, назовите их live и dev соответственно, оба работают с postgresql. Я могу видеть и то, и другое без проблем с помощью pgadmin4, и оба они полностью функциональны: один за действующим веб-сайтом, а другой, когда я запускаю веб-сайт в режиме отладки в моем окне разработчика. Довольно обычная установка.

В течение многих лет я запускал один и тот же сценарий bash, который я написал, который выгружает живую базу данных, а затем восстанавливает ее в окне разработчика, поэтому у меня есть последний живой снимок для работы.

Сегодня это меня не подводит с заголовком:

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

Я пытался диагностировать это, и много искал в Интернете, но сбился с толку и потерпел неудачу, поэтому здесь я готов поделиться своим опытом.

В помощь я поделюсь следующим:

$ 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

Данные pg_dump и pg_restore являются идентичными версиями и:

$ 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

Я вижу, что это не просто идентичные версии, но они выполняются одним и тем же сценарием-оболочкой (который оказался сценарием perl - теперь это язык, который вы больше не видите, и я использовал много кода)

Так что я в полном недоумении. Думая, что на живой машине может быть проблема с версией:

$ 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)

Я вижу, что в live-боксе есть немного более старая версия pg_dump (что имело бы значение только в том случае, если pg_dump в моем dev-боксе каким-то образом использовал RPC для live-бокса для запуска своего pg_dump).

Теперь, возможно, есть небольшая подсказка в том, что мой блок разработчика видел несколько обновлений postgresql, например:

$ 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

Кластеры 11 и 12 остаются неиспользованными, о чем свидетельствуют пустые файлы журнала. Я использую 10. Но я заметил, что:

$ 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)

что слегка подозрительно, но, опять же, не является очевидной причиной или связью:

1. Я использую pg_dump, а не psql
2. Я использую только инструменты pg dev box, а не live box (они не должны иметь значения, теоретически вся передача данных через порт 5432 на live box, который доставляет дамп базы данных в pg_dump на моем dev box).

Вот кластеры на коробке любви, и это порт 5432, который на live.lan я запускаю 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

Я сейчас глубоко озадачен и расстроен этим. Был бы глубоко признателен за продвижение подсказок. Если мне придется порыться в темноте, я, вероятно, снова деинсталлирую postgres 11 и 12 и посмотрю, поможет ли это, иначе мне придется отслеживать /usr/share/postgresql-common/pg_wrapper, чтобы увидеть, как и где два пути pg_dump и pg_restore расходятся по несовместимой версии пути.

Обновление:

Еще одна подсказка, которую я обнаружил, которая позволяет мне обходной путь, но просто углубляет загадку, заключается в следующем:

$ 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 test2.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)

Это невероятное недоумение. Единственно возможные объяснения:

1. несмотря на то, что в отчетах указаны идентичные номера версий, два pg_dump различны. Я бы исключил это как невероятное.
2. pg_dump запускает pg_wrapper, который запускает / usr / lib / postgresql / 10 / bin / pg_dump с некоторыми загадочными аргументами, которые его нарушают!

Второй вариант вероятен и потребует от меня инструмента pg_wrapper для диагностики.

Обновление 2:

И еще один инструментарий pg_wrapper позже. В конце концов, pg_dump запускает pg_wrapper, который запускает /usr/lib/postgresql/12/bin/pg_dump, но работает /usr/lib/postgresql/10/bin/pg_restore ... Вперед! Начинаю думать, что это ошибка совместимости версий postgresql!

Обновление 3:

Заглянув глубже в pg_wrapper, выяснил причину, и да, я бы сказал, что это своего рода ошибка pg_wrapper, хотя она может быть спорной, хотя ИМХО вряд ли. Вот что он делает:

Если указан --host, то он использует самую последнюю установленную версию postgresql (в моем случае 12, и это для pg_dump, поэтому pg_dump 12 создает дамп)

Если --host не указан, он обращается к конфигурации пользователя (в моем случае 10, и это для pg_restore, поэтому pg_restore 10 запущен и не может прочитать файл, созданный pg_dump 12).

Так почему это ошибка? Потому что у меня есть конфигурация использования, и я бы хотел, чтобы она уважалась независимо от того, разговариваю ли я с удаленным хостом. Более того, если я укажу хост, я определенно не ожидаю, что буду использовать последнюю локальную версию, игнорируя локальную конфигурацию. Я ожидаю, что либо будет соблюдаться локальная конфигурация (как в случае, когда удаленный хост не указан), либо попытаться сопоставить версию хостов rmeote. Произвольная опора на последнюю установленную версию ИМХО глубоко сомнительна.

НО оказывается, что есть обходной путь, который работает. По сути вместо:

sudo -u postgres pg_restore -l test.backup

это работает:

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

По иронии судьбы указав хост, мы заставляем его игнорировать локальные конфигурации и использовать новейшую версию pg_restore, которая, похоже, отлично работает при восстановлении в кластере PG 10.