Для тех, кто столкнулся с той же проблемой, вот краткое резюме (составленное ИИ) моих действий:
Временно запустите PG15 → сделайте дамп базы данных → используйте PG18 → восстановите дамп
Вижу, что ты это исправил, но метод, который дал ChatGPT, хотя и устранил ошибку, всё же очистил мою базу данных, так что по сути не осталось ни аккаунтов, ни тем, ни сообщений.
К счастью, это был относительно новый форум для разработчиков, поэтому потеря не слишком велика.
Мы проявили большую осторожность, чтобы этого не произошло сегодня. После каждого шага система сообщала мне, что ничего не будет удалено, и у меня сложилось впечатление, что мы трижды проверяли, все ли данные были перенесены, прежде чем согласились удалить больше не нужные нам файлы.
Но даже если бы что-то пошло не так, единственными данными, которые я бы потерял, были бы настройки компонентов темы.
Привет! У меня есть форум с довольно большой базой данных (около 80 ГБ). Для перехода с версии 13 на 15 я сменил сервер, выполнил новую установку и восстановил данные.
Вы также рекомендуете такой способ перехода? (Я пробовал выполнить обновление, но получил ошибки, связанные с кодовой страницей).
Мы стараемся предоставлять разумные значения по умолчанию в образах discourse_docker, но невозможно учесть все возможные варианты использования. Не стесняйтесь настраивать свои образы, чтобы отложить обновление версий, если вам так удобнее.
В определённой степени версии зависимостей отражают наши требования к хостингу — мы используем базовый образ внутри нашей инфраструктуры. Это означает, что он не должен слишком сильно устаревать, но также означает, что количество поддерживаемых нами комбинаций ограничено.
Это совершенно валидный метод, если он вам более привычен.
Если предупреждение возникает при подготовке к дампу старой БД, то беспокоиться не о чем. Мы запускаем сервер только против старой директории данных для того, чтобы выполнить pg_dump. Когда дамп восстанавливается на новом сервере, индексы пересоздаются.
Причина, по которой вы это видите, заключается в том, что в последние несколько дней мы выпустили новую версию базового образа, которая обновляется с Debian Bookworm до Trixie, меняя версию glibc. Локали, основанные на провайдере libc (который вы, вероятно, использовали), не являются стабильными при обновлениях glibc, поэтому, когда скрипт обновления запускает сервер Postgres для дампа ваших старых данных, он выводит предупреждения о несовпадении сортировки.
Несовпадение сортировки — это именно та причина, по которой мы выполняем дамп и восстановление вместо использования pg_upgrade. Как только ваша БД будет использовать C.UTF-8 с провайдером builtin, обновления glibc больше не будут влиять на сортировку.
Я выполнил обновление сегодня вечером, и всё прошло по плану. Я получил те же предупреждения о сортировке базы данных, но, похоже, их можно игнорировать. Спасибо.
чтобы отложить обновление, но получил следующую ошибку
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.
Похоже, что у тебя неправильный базовый контейнер. Ты выполнил ./launcher rebuild? Это должно запустить git pull, но, возможно, стоит попробовать выполнить git pull вручную, чтобы проверить, изменится ли ситуация.
Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Status: Downloaded newer image for discourse/base:2.0.20260812-0036 docker.io/discourse/base:2.0.20260812-0036
Ensuring launcher is up to date
Launcher is up-to-date
Stopping old container
/usr/bin/docker stop -t 600 app
app
2.0.20260812-0036: Pulling from discourse/base
Digest: sha256:837e8ed4b5916baa36856b842ad84fe262b6b1b5550701f8844b13cc7acad7a5
Status: Image is up to date for discourse/base:2.0.20260812-0036 docker.io/discourse/base:2.0.20260812-0036
/usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2026-08-25T06:22:16.249062 #1] INFO – : Reading from stdin
I, [2026-08-25T06:22:16.274434 #1] INFO – : File > /etc/service/postgres/run chmod: +x chown:
I, [2026-08-25T06:22:16.281650 #1] INFO – : File > /etc/service/postgres/log/run chmod: +x chown:
I, [2026-08-25T06:22:16.287846 #1] INFO – : File > /etc/runit/3.d/99-postgres chmod: +x chown:
I, [2026-08-25T06:22:16.293208 #1] INFO – : File > /root/install_postgres chmod: +x chown:
I, [2026-08-25T06:22:16.299851 #1] INFO – : File > /root/upgrade_postgres chmod: +x chown:
ОШИБКА
Errno::ENOENT: No such file or directory @ rb_sysopen - /etc/postgresql/15/main/postgresql.conf
Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/replace_command.rb:11:in ‘IO.read’
replace failed with the params {“filename” => “/etc/postgresql/15/main/postgresql.conf”, “from” => “data_directory = ‘/var/lib/postgresql/15/main’”, “to” => “data_directory = ‘/shared/postgres_data’”}
bootstrap failed with exit code 1
** ОШИБКА ПРИ ИНИЦИАЛИЗАЦИИ ** прокрутите вверх и найдите более ранние сообщения об ошибках, их может быть несколько.
./discourse-doctor может помочь диагностировать проблему.
2d15a756bfd82ed45debfbb4936784721293a3aeecabe8ba9b58c64d4bbe16e1
Текущий базовый образ устанавливает сервер PostgreSQL 18, но postgres.15.template.yml по-прежнему предполагает, что пакеты сервера PostgreSQL 15 уже присутствуют. В результате он обращается к:
/etc/postgresql/15/main/postgresql.conf
до того, как этот файл будет создан, что приводит к ошибке ENOENT, описанной выше.
Я открыл небольшой PR, в котором шаблон для удержания PostgreSQL 15 удаляет пакеты сервера PostgreSQL 18 и устанавливает пакеты сервера PostgreSQL 15 перед настройкой PostgreSQL:
Это должно восстановить предполагаемый сценарий, при котором замена postgres.template.yml на postgres.15.template.yml откладывает обновление до PostgreSQL 18.
Как прошёл апгрейд у тех, у кого несколько контейнеров на одном сервере? Если на выходных будет время, возможно, обновлю и наш сервер — просто решил сначала спросить здесь, вдруг пока лучше подождать..
да, я делал апгрейд двойных контейнеров на одном сервере пару недель назад (в том числе и на российском сервере). Проблем не было вообще, но сначала убедитесь, что у вас достаточно места на диске.
Совет всем, кто обновляет Postgres вне Docker. Можно использовать --link в pg_upgrade, чтобы не копировать данные, а создать жёсткие ссылки. Это экономит место на диске.