Во время обновления я получал
Остановка сервера базы данных PostgreSQL 15: main
Ошибка: владелец конфигурации (postgres:101) и владелец данных (runit-log:999) не совпадают, а владелец конфигурации не является root … не удалось!
не удалось!
не удалось открыть файл версии “/shared/postgres_data/PG_VERSION”: Отказано в доступе
Сбой, выход
Это было решено с помощью
sudo ./launcher enter app
а затем
chown -R postgres:postgres /shared/postgres_data
chown -R postgres:postgres /shared/postgres_run
chmod -R 700 /shared/postgres_data
Я нахожусь в бесконечном цикле: база данных обновилась успешно, но при запуске ./launcher rebuild app процесс просто зацикливается. Я вижу только следующее:
РЕДАКТИРОВАНО: Нашел это сообщение…
mv: межсетевого перемещение не удалось: '/shared/postgres_data_new' в '/shared/postgres_data/postgres_data_new'; невозможно удалить целевой объект: Каталог не пуст
В вашей установке есть расширения, которые следует обновить
с помощью команды ALTER EXTENSION. Файл
update_extensions.sql
при выполнении через psql суперпользователем базы данных обновит
эти расширения.
Пожалуйста, дайте совет.
Обновление завершено
----------------
Статистика оптимизатора не переносится pg_upgrade.
После запуска нового сервера рекомендуется выполнить:
/usr/lib/postgresql/15/bin/vacuumdb --all --analyze-in-stages
Выполнение этого скрипта удалит файлы данных старого кластера:
./delete_old_cluster.sh
-------------------------------------------------------------------------------------
ОБНОВЛЕНИЕ POSTGRES ЗАВЕРШЕНО
Старая база данных версии 13 хранится в /shared/postgres_data_old
Чтобы завершить обновление, выполните повторную сборку с помощью:
./launcher rebuild app
-------------------------------------------------------------------------------------
Хорошо, похоже, проблема именно здесь:
Эти файлы находятся в shared/standalone/ и уже были перемещены вручную…
mv: невозможно переместить '/shared/postgres_data' в '/shared/postgres_data_old': Устройство или ресурс занят
mv: межсетевого перемещение не удалось: '/shared/postgres_data_new' в '/shared/postgres_data/postgres_data_new'; невозможно удалить целевой объект: Каталог не пуст
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Генерация локалей (это может занять некоторое время)...
Кажется, ни одно решение не работает. Это так раздражает.
Это было бы очень необычно, если бы кто-то просто предложил такую услугу, не будучи предварительно запрошенным.
Если вы хотите нанять кого-то, вот нужное место: Marketplace - Discourse Meta
Ваша многосайтовая инсталляция перестала работать после обновления. Появилось сообщение:
Ваша установка содержит расширения, которые необходимо обновить с помощью команды ALTER EXTENSION. Файл
update_extensions.sql
при выполнении через psql пользователем с правами суперпользователя базы данных обновит эти расширения.
Я не могу найти файл update_extensions.sql нигде. Где он может находиться?
Проверьте это
mv: не удалось переместить '/shared/postgres_data' в '/shared/postgres_data_old': Устройство или ресурс занят
mv: перемещение между устройствами не удалось: '/shared/postgres_data_new' в '/shared/postgres_data/postgres_data_new'; не удалось удалить цель: Каталог не пуст
I, [2025-02-08T15:22:42.078189 #1] INFO -- : Генерация локалей (это может занять некоторое время)...
Это был я. Я предлагаю помощь, когда вижу, что кто-то оказался в ситуации, которую будет трудно разрешить с помощью здесь.
Вопрос из любопытства.
Существует ли стандарт или стратегия, касающаяся обновлений ключевых компонентов, таких как Postgres?
Я вижу, что поддержка Postgres 13 действовала до 25 ноября, поддержка версии 15 — до 2027 года, а текущая версия — 17.
Просто хочу разобраться и понять. Обновление версий базы данных обычно является серьёзной задачей и требует значительных усилий.
Спасибо!
Я работаю ещё с версии PostgreSQL 10. Обычно они обновляются каждые два релиза, хотя в этот раз перешли с 12 на 13, так как в ней были улучшения, которые сделали раннее обновление целесообразным. Я немного удивился, что они не перешли сразу на 16.
Обычно процесс проходит довольно гладко, если у вас достаточно места на диске и актуальная версия Docker.
Я вернулся к шаблону 13, пока не будет исправление, спасибо
Я решил проблему, с которой столкнулся при обновлении PostgreSQL с версии 13 до 15. После восстановления сервера из резервных копий после неудачного обновления мне помогли следующие шаги с локалью PostgreSQL en_GB.UTF-8:
sudo -i
su - discourse
cd /var/discourse
git stash
git stash drop
git pull
./launcher stop app
docker run --rm \
--entrypoint=/bin/bash \
-e LANG='en_GB.UTF-8' \
-v /var/discourse/shared/standalone/postgres_data:/var/lib/postgresql/13/data \
-v /var/discourse/shared/standalone/postgres_data_new:/var/lib/postgresql/15/data \
tianon/postgres-upgrade:13-to-15 \
-c 'sed -i "s/^# $LANG/$LANG/" /etc/locale.gen && locale-gen &&
apt-get update && apt-get install -y postgresql-13-pgvector postgresql-15-pgvector &&
docker-upgrade'
exit
mv /var/discourse/shared/standalone/postgres_data /var/discourse/shared/standalone/postgres_data_old
mv /var/discourse/shared/standalone/postgres_data_new /var/discourse/shared/standalone/postgres_data
chown -R 101:104 /var/discourse/shared/standalone/postgres_data
su - discourse
cd /var/discourse
docker run --rm -v /var/discourse/shared/standalone:/shared \
local_discourse/app chown -R postgres:postgres /shared/postgres_data
./launcher rebuild app
Мне пришлось удалить локальные изменения, которые ранее были внесены для настройки LANG в PostgreSQL, с помощью команд git stash; git stash drop. Перемещение директорий с данными PostgreSQL требовало выполнения от имени root, а также было необходимо выполнить команду chown.
Нужно ли на этот раз выполнить git pull? Обычно это не требуется.
Сейчас это никогда не требуется, так как rebuild делает это за вас.
Сообщение Device or resource busy в конце первой ошибки указывает на то, что кто-то удерживает блокировку каталога postgres_data, поэтому его невозможно переместить.
Поскольку это каталог базы данных, наиболее вероятное объяснение — postgres_data является точкой монтирования. Это ещё более вероятно, учитывая сообщение inter-device move failed во второй команде mv, что означает, что shared/postgres_data_new и shared/postgres_data находятся на разных дисках или разделах.
Если вы подтвердите, что postgres_data — это точка монтирования, вам придётся вручную переместить все файлы из postgres_data в какой-либо другой резервный каталог, а затем переместить все файлы изнутри postgres_data_new в (теперь пустой) каталог postgres_data. Оба перемещения следует выполнить после завершения первой пересборки с сообщением UPGRADE OF POSTGRES COMPLETE, но перед запуском второй.
Если postgres_data не является точкой монтирования, вам поможет утилита lsof. С её помощью можно попытаться определить, что вызывает блокировку.
Конечно, сначала создайте необходимые резервные копии.
Это отлично, спасибо.
Файлы находились в следующей папке:
/var/postgres_data_discourse как postgres_data_new
Это помогло исправить ситуацию.
Я переместил postgres_data_new в /var.
Переименовал postgres_data_discourse в postgres_data_discourse_old.
Переименовал postgres_data_new в postgres_data_discourse.
Выполнил ./launcher rebuild app.
Ещё раз спасибо 
У меня база данных объёмом 62 ГБ. Какое решение вы посоветуете для оптимального обновления?
62G /var/discourse/shared/standalone/postgres_data
Я рекомендую перенести всё на новую виртуальную машину, развернуть новый экземпляр Discourse с пустой базой данных (при желании скопировав каталоги ssl и letsencrypt для обеспечения переключения без простоя) и восстановить текущую базу данных на новый сервер. Это позволит выполнить обновление без простоя и с нулевым риском возникновения ошибок.
В любом случае, скорее всего, уже пора обновить вашу операционную систему.
Это хорошая идея.
Могу ли я перенести
резервную копию версии 3.4.0.beta4-dev ### на новую установку последней версии?
Если вы спрашиваете, можно ли восстановить любую старую версию Discourse до любой новой версии Discourse, которую вы можете получить, ответ — да.