Значит, вы где-то изменили порт PostgreSQL с 5432 на 50432? (Или, возможно, это делает код миграции, и я этого не замечал).
Может быть, стоит переключиться на шаблон postgres13, как было предложено в первом посте? Если это сработает, я бы перенёс всё на новый сервер, чтобы избежать проблем с переходом на новую версию PostgreSQL, и просто восстановил базу данных на новом сервере.
У меня недостаточно места для выполнения этого обновления на разделе Discourse. Однако на другом диске у меня много свободного места. Можно ли использовать его для временного хранения?
В любом случае, скорее всего, пора обновить операционную систему, а переход на новую виртуальную машину — это гораздо проще, требует минимального простоя, и в случае чего у вас всё равно останется работающий сервер.
Если у вас есть отдельный контейнер с данными, можно попробовать перенести всё содержимое /var/discourse/shared/data на другой раздел и соответствующим образом изменить тома в вашем YML-файле.
А если отдельного контейнера нет, можно сделать что-то подобное, хотя это будет немного сложнее.
У меня похожая (та же?) проблема. Вы проверяли упомянутый лог?
В моём случае: при обновлении сначала возникла проблема, что контейнер приложения (в моём случае только веб-версия) не пересобирается, потому что я добавил rss-polling как пользовательский плагин, и это, похоже, конфликтует с новыми настройками по умолчанию. После его удаления всё заработало.
Но затем возникли проблемы с отсутствующим векторным расширением. Это произошло потому, что я давно не пересобирал контейнер данных. Мне удалось обновить его до версии 13, но теперь я застрял на 13-й версии: когда я меняю data.yaml на postgres.template или postgres.15.template, миграция не выполняется.
Сначала она не удавалась с ошибкой «unclean shutdown», но с учётом приведённых выше подсказок мне удалось это исправить. Однако теперь миграция снова не проходит, поскольку, похоже, отсутствует установка версии 13? Возможно, это связано с остатками в директории /shared? (Я уже пытался очистить директорию postgres_new).
-----------------------------------------------------------------
pg_upgrade запущен в пт, 17 окт 2025, 09:54:37
-----------------------------------------------------------------
команда: "/usr/lib/postgresql/13/bin/pg_ctl" -w -l "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" -D "/shared/postgres_data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directories='/var/lib/postgresql'" start >> "/shared/postgres_data_new/pg_upgrade_output.d/20251017T095437.518/log/pg_upgrade_server.log" 2>&1
ожидание запуска сервера....2025-10-17 09:54:37.744 UTC [1900] LOG: запуск PostgreSQL 13.22 (Debian 13.22-1.pgdg12+1) на x86_64-pc-linux-gnu, скомпилирован с помощью gcc (Debian 12.2.0-14+deb12u1) 12.2.0, 64-бит
2025-10-17 09:54:37.749 UTC [1900] LOG: прослушивание Unix-сокета "/var/lib/postgresql/.s.PGSQL.50432"
2025-10-17 09:54:37.760 UTC [1900] LOG: не удалось открыть файл конфигурации "/etc/postgresql/13/main/pg_hba.conf": файл или каталог не найден
2025-10-17 09:54:37.760 UTC [1900] FATAL: не удалось загрузить pg_hba.conf
2025-10-17 09:54:37.762 UTC [1900] LOG: система баз данных остановлена
ожидание прекращено
pg_ctl: не удалось запустить сервер
Проверьте вывод лога.
```
Скорее всего, я бы вернулся к PG13 с использованием старого контейнера (если получится это сделать), затем сделал бы резервную копию и переехал на новый сервер (вам, вероятно, всё равно потребуется новая ОС).
Похоже, что ваш контейнер находится в повреждённом состоянии. Пытается ли он пересобраться с шаблоном PG13? Возможно, вам нужно переместить папку резервной копии postgres в postgres_data и снова переключиться на версию 13, чтобы всё заработало.
Да, я сейчас работаю с контейнером PG13. Я пересоздавал его много раз. Я даже очистил зависающую директорию _new. Но каждый раз, когда я пытаюсь перейти к версии 15 или к официальному шаблону без указания версии, это не удаётся. Если это не исправится само, я скоро перенесу его вручную. Не вижу, как ОС здесь имеет значение.
Кстати, последовательность скриптов в postgres.15.template и postgres.template различается. Какой из них лучше для обновления?
Я бы изменил структуру монтирования тома так, чтобы весь каталог Shared или shared/postgres находился на одном томе. Тогда переименование каталогов (которое требуется регулярно) больше не будет проблемой.
Это может не иметь отношения к текущей проблеме. Однако часто бывает так, что если вы используете Discourse достаточно долго, чтобы потребовалось обновление PostgreSQL, то, скорее всего, пришло время и для обновления операционной системы.
Переход на новый сервер позволяет сделать это практически без простоя и без риска оказаться в нерабочем состоянии.
С другой стороны, большинство обновлений, которые я запускал своим скриптом (который просто выполняет описанные здесь действия), прошли без проблем.
Думаю, вам стоит переключиться на неверсионированный файл, а затем выполнить две пересборки.