При попытке выполнить резервное копирование системы я получаю сообщение: «Резервное копирование не удалось. Проверьте журналы». В журнале записано: pg_dump: [archiver (db)] подключение к базе данных «discoursedb» не удалось: отказано в соединении с сервером.
Полагаю, что здесь могут быть две проблемы:
Удалённый сервер работает на нестандартном порту.
Удалённый PostgreSQL использует более новую версию PSQL.
Когда я захожу в приложение (/var/discourse/launcher enter app) и выполняю ручное резервное копирование, то изначально, без указания порта, получаю точно такую же ошибку:
$ pg_dump -h 123.456.789.101 -U username -W -F t discourse_db > discourse_db_backup.tar
Password:
pg_dump: [archiver (db)] подключение к базе данных «discourse_db» не удалось: отказано в соединении с сервером
Работает ли сервер на хосте «123.456.789.101» и принимает ли он
TCP/IP-соединения на порту 5432?
Это легко исправить (ЗА ИСКЛЮЧЕНИЕМ того, что я не знаю, как заставить Discourse использовать правильный порт при резервном копировании), однако следующая проблема вызывает больше беспокойства: на сервере базы данных используется более новая версия PSQL:
$ pg_dump -h 123.456.789.101 -p 45678 -U username -W -F t discourse_db > discourse_db_backup.tar
Password:
pg_dump: версия сервера: 11.5 (Ubuntu 11.5-3.pgdg18.04+1); версия pg_dump: 10.10 (Debian 10.10-1.pgdg100+1)
pg_dump: прерывание из-за несоответствия версий сервера
Что можно сделать в такой ситуации? Существует ли способ восстановить работоспособность системного резервного копирования в данном случае, или же Discourse и база данных PostgreSQL необходимо резервировать отдельно?
Если единственный вариант — второе, то как ПРАВИЛЬНО выполнять резервное копирование хотя бы данных? Существует ли предпочтительный согласованный механизм для одновременного выполнения обоих типов резервного копирования без необходимости писать новый скрипт?
Я действительно нашел обсуждение в другом посте, где речь шла о ситуации, немного схожей с моей. Главное отличие в моем случае заключается в том, что мы храним файлы на локальном сервере, а не в S3. Я мог бы отказаться от резервного копирования PostgreSQL, так как оно выполняется независимо, однако мне все же необходимо делать резервные копии:
локального контента и
настроек Discourse.
Мне по-прежнему хотелось бы иметь единый пакет резервной копии, включающий базу данных, контент и настройки в одном месте, но, полагаю, вы не поддерживаете или не будете поддерживать такую возможность. Поэтому я хотел бы хотя бы объединить контент и настройки в один пакет.
Postgres 11 не поддерживается. Вы можете поискать информацию о восстановлении между версиями в другом месте, но для работы Discourse с pg11 потребуется определённая работа.
Интересно и странно. Я где-то читал, что 11-я версия в порядке, но помимо этого у меня уже развернута система на 11-й версии, и пока что я не сталкивался с ошибками или проблемами (кроме резервного копирования)… Теперь вы меня беспокоите…
Да. У меня развернуто две системы на PostgreSQL 11. Они работают нормально, за исключением того, что я выполняю резервное копирование напрямую. Я обновил PostgreSQL до версии 11 в контейнере. Они создают резервные копии, но не могут их восстановить.
Система резервного копирования Discourse должна просто выводить предупреждение, а не завершаться с ошибкой при несоответствии версий PostgreSQL. Я только что попытался создать резервную копию самостоятельно, и поскольку я тоже использую внешний сервер PG, архив tarball не был создан вообще.
Со мной произошла та же проблема. Я перенес базу данных PostgreSQL на отдельный сервер и начал получать ошибки при резервном копировании. Я нашел решение, удалив и переустановив PostgreSQL в Docker на основном сервере.
cd /var/discourse
./launcher enter app
apt-get remove postgresql-client-common
apt-get update
sudo apt-get install postgresql