Tôi có một máy chủ và hộp phát triển trực tiếp, gọi chúng là live và dev tương ứng cả chạy postgresql. Tôi có thể thấy cả hai và quản lý cả hai với pgadmin4 mà không gặp sự cố, và cả hai đều có đầy đủ chức năng, một trang web trực tiếp và trang kia khi tôi chạy trên trang web ở chế độ gỡ lỗi trên hộp dev của tôi. Thiết lập khá bình thường.
Trong nhiều năm, tôi đã chạy cùng một tập lệnh bash mà tôi đã viết để loại bỏ cơ sở dữ liệu trực tiếp sau đó khôi phục nó trên hộp dev để tôi có ảnh chụp nhanh trực tiếp mới nhất để làm việc.
Hôm nay điều này làm tôi thất vọng với thông điệp có tiêu đề:
pg_restore: [archiver] unsupported version (1.14) in file headerTôi đã cố gắng chẩn đoán điều này, và tìm kiếm rộng rãi trên mạng nhưng bị liệt giường và đã thất bại vì vậy ở đây tôi đang nắm trong tay chuyên môn.
Để giúp tôi sẽ chia sẻ như sau:
$ 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 headerCho pg_dump và pg_restore là các phiên bản giống hệt nhau và:
$ 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_wrapperTôi có thể thấy chúng không chỉ là các phiên bản giống hệt nhau mà được điều hành bởi cùng một tập lệnh bao bọc (điều này xảy ra là một tập lệnh perl - bây giờ đó là ngôn ngữ bạn không thấy nhiều nữa và tôi đã sử dụng để viết mã rộng rãi)
Vì vậy, tôi hoàn toàn bối rối. Suy nghĩ có thể có một vấn đề phiên bản với máy trực tiếp:
$ 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)Tôi có thể thấy hộp trực tiếp có phiên bản cũ hơn một chút của pg_dump (điều này chỉ quan trọng nếu pg_dump trên hộp dev của tôi bằng cách nào đó đã sử dụng RPC cho hộp trực tiếp để chạy pg_dump của nó).
Bây giờ có thể có một manh mối nhỏ trong thực tế là hộp dev của tôi đã thấy một vài nâng cấp postgresql đi qua và ví dụ:
$ 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.logCác cụm 11 và 12 vẫn không được sử dụng như bằng chứng của các tệp nhật ký trống. Tôi đang sử dụng 10. Nhưng tôi nhận thấy rằng:
$ 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)đó là cá nhẹ nhưng một lần nữa rõ ràng không phải là một nguyên nhân hoặc liên quan:
- Tôi đang sử dụng pg_dump chứ không phải psql
- Tôi chỉ sử dụng các công cụ pg của hộp dev chứ không phải các hộp sống (chúng không liên quan, toàn bộ dữ liệu truyền theo lý thuyết qua cổng 5432 trên hộp trực tiếp cung cấp kết xuất dữ liệu cho pg_dump trên hộp dev của tôi.
Dưới đây là các cụm trên hộp tình yêu và trên cổng 5432 trên live.lan Tôi đang chạy 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.logTôi rất bối rối và bị cản trở bởi hiện tại. Sẽ đánh giá cao sâu sắc chuyển tiếp manh mối. Nếu tôi bị buộc phải câu cá trong bóng tối, tôi sẽ gỡ bỏ cài đặt lại postgres 11 và 12 và xem điều đó có giúp ích gì không, cuối cùng tôi sẽ phải theo dõi /usr/share/postgresql-common/pg_wrapperđể xem cách thức và nơi hai đường dẫn của pg_dump và pg_restore chuyển hướng xuống các đường dẫn phiên bản không tương thích .
Cập nhật:
Một manh mối nữa tôi đã phát hiện ra, điều đó cho phép tôi một cách giải quyết nhưng chỉ đơn giản là làm sâu sắc thêm bí ẩn như sau:
$ 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)Đó là sự bối rối ngoài niềm tin. Những lời giải thích duy nhất có thể:
- mặc dù báo cáo số phiên bản giống hệt nhau, hai pg_dumps là khác nhau. Tôi sẽ loại trừ điều này là vượt quá niềm tin.
- pg_dump chạy pg_wrapper chạy / usr / lib / postgresql / 10 / bin / pg_dump với một số đối số bí ẩn phá vỡ nó!
Thứ hai là hợp lý và sẽ yêu cầu tôi sử dụng công cụ pg_wrapper để chẩn đoán.
Cập nhật 2:
Và một thiết bị của pg_wrapper sau. Nó chứng minh rằng pg_dump chạy pg_wrapper chạy /usr/lib/postgresql/12/bin/pg_dumpnhưng nó vẫn chạy /usr/lib/postgresql/10/bin/pg_restore... Hãy hình! Bắt đầu nghĩ rằng đây là một lỗi tương tác phiên bản postgresql!
Cập nhật 3:
Nhìn sâu hơn pg_wrapper, đóng đinh nguyên nhân, và vâng, tôi cho rằng đó là lỗi pg_wrapper của một loại mặc dù nó có thể gây tranh cãi, hầu như không phải là IMHO. Đây là những gì nó làm:
Nếu --host được cung cấp thì nó sử dụng phiên bản mới nhất của postgresql được cài đặt (12 trong trường hợp của tôi và đây là cho pg_dump, vì vậy pg_dump 12 tạo kết xuất)
Nếu --hostkhông được cung cấp thì nó sẽ cấu hình người dùng (10 trong trường hợp của tôi và đây là cho pg_restore, vì vậy pg_restore 10 được chạy và nó không thể đọc tệp được tạo bởi pg_dump 12).
Vậy tại sao đây là một lỗi? Bởi vì tôi có một cấu hình sử dụng và tôi muốn nó tôn trọng dù tôi có nói chuyện với một máy chủ từ xa hay không. Hơn nữa, nếu tôi chỉ định một máy chủ lưu trữ, tôi chắc chắn không mong đợi sử dụng phiên bản cục bộ mới nhất bỏ qua cấu hình cục bộ. Tôi mong muốn tôn trọng cấu hình cục bộ (như trường hợp khi không có máy chủ từ xa nào được chỉ định) hoặc thử khớp với phiên bản máy chủ rmeote. Tự ý dựa vào phiên bản cài đặt mới nhất là IMHO nghi vấn sâu sắc.
NHƯNG hóa ra có một cách giải quyết. Về cơ bản thay vì:
sudo -u postgres pg_restore -l test.backupnhững công việc này:
sudo -u postgres pg_restore --host=localhost -l test.backupBằng cách chỉ định máy chủ một cách trớ trêu, chúng tôi buộc nó bỏ qua các cấu hình cục bộ và sử dụng phiên bản mới nhất của pg_restore, có vẻ như hoạt động tốt để khôi phục lại cụm 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.psqlnhưng nó không hoạt động. Tôi cũng nhận được lỗi tương tự trong khi nhập một cơ sở dữ liệu.
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.