Проблема с пересборкой из-за медленного завершения работы базы данных

Это рекомендованное обновление не удалось, и после сбоя форум не был восстановлен. Я запускаю discourse-doctor, чтобы попытаться исправить проблему. Если это тоже не поможет, я сделал снимок виртуальной машины.

Вывод:

2023-04-19 18:28:31.298 UTC [42] LOG:  получен запрос быстрого завершения работы
2023-04-19 18:28:33.651 UTC [65] LOG:  завершение работы
2023-04-19 18:28:33.974 UTC [42] LOG:  система баз данных завершена


ОШИБКА
--------------------
Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' завершился с ошибкой, статус процесса: #<Process::Status: pid 59 exit 2>
Место ошибки: /usr/local/lib/ruby/gems/3.2.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
Ошибка выполнения с параметрами: "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
Инициализация завершена с кодом выхода 2
** ИНИЦИАЛИЗАЦИЯ ПРОВАЛЕНА ** Пожалуйста, прокрутите вверх и найдите предыдущие сообщения об ошибках, их может быть несколько.
./discourse-doctor может помочь в диагностике проблемы.
c13e1ba313de8fc84f6e2fb0f88197a908803c39791283effb8c82f55b56b6dc
Команда завершилась с ненулевым статусом 1
1.85user 1.84system 3:21.56elapsed 1%CPU (0avgtext+0avgdata 36996maxresident)k
197608inputs+368outputs (1133major+96509minor)pagefaults 0swaps

Вы находитесь в бета-ветке?

Вы можете попробовать перезапустить свой контейнер с помощью

 ./launcher start app

но именно это и должен делать discourse-doctor.

Вам нужно предоставить больше вывода, так как ошибка находится выше того, что вы включили.

Да, мы находимся на бета-ветке. Я всегда запускаю в nohup, поэтому у меня есть полный лог.

Discourse-doctor всё ещё работает, но пока не упал, так что я надеюсь.

https://pastebin.mozilla.org/iw2zc5zd

Редактирование: Discourse-doctor вернул нас в строй.

По сути, я сам этого хотел — обновился через час после этого уведомления и стал первым, кто это сделал. Никакого реального стресса с этим снимком состояния до этого, поэтому я взял на себя эту задачу для команды, ребята.

  • 2023-04-19 18:28:26.755 UTC [45] LOG: система баз данных была завершена некорректно; выполняется автоматическое восстановление

Если ваша база данных не может безопасно остановиться за 60 секунд (что может произойти с большими БД на медленных дисках), она перейдёт в это состояние и завершится неудачей при перестроении, если не сможет восстановиться за 5 секунд (что бывает редко, поскольку такие базы большие и медленные).

Это не имеет никакого отношения к изменениям, перечисленным здесь, и является проблемой в Discourse как минимум с 2016 года.

Ах, спасибо. Возможно, стоит подождать подольше для таких крупных форумов, как наш. Если просто завершить процесс базы данных, то после перезапуска ему потребуется откатить транзакции, что может занять очень много времени.

Терминология в отношении бета-версии немного запутывает. В панели администратора указано, что мы используем бета-версию; неужели нам стоило посмотреть что-то ещё? Насколько я понимаю, для Discourse рекомендуется именно бета-версия, так как в анонсах релизов не рекомендуется использовать стабильную ветку.

По умолчанию используется значение tests_passed, которое считается готовым к производству.

Какого размера ваша база данных? Она находится на SSD? Сколько у вас оперативной памяти?

Использование отдельного контейнера для данных потребует меньшего количества перезапусков базы данных.

Когда было принято решение о 60 секундах для безопасного завершения работы? Сколько установок сейчас значительно больше, чем это было тогда нормой?

В идеале эта 60-секундная задержка должна быть больше похожа на ожидание с обратной связью, но с ограничением. Похоже, что ограничение должно быть выше, если сейчас существует много экземпляров, которые уязвимы.

Это 105 ГБ на SSD, ВМ с 16 ГБ ОЗУ, и я выделил для PostgreSQL буферный пул размером 8 ГБ.

Кажется, я видел, что это было ещё в 2016 году. Но многое изменилось. РЕДАКТИРОВАНИЕ: Вот новый коммит.

Не думаю, что много на стандартной установке, поскольку так было почти с самого начала.

Ага, да. Это большая база данных. Сомневаюсь, что у многих есть настолько большая база данных, которая не находится в RDS или хотя бы в отдельном контейнере. Вам, вероятно, стоит подумать о переходе на установку с двумя контейнерами.

Мы это учтём. Документирован ли метод переключения? И есть ли какие-либо другие преимущества, которые не даст увеличение таймера до 60 секунд?

Я увеличил его до 10 минут вчера.

Отлично, я подумал, что он опубликовал оригинальный коммит ещё в 2016 году. Так есть ли для нас какие-то преимущества?

Вы можете ознакомиться с этим по ссылке: Move from standalone container to separate web and data containers

Вы можете создать новый контейнер, пока старый продолжает работать. Вам не нужно останавливать базу данных для создания нового контейнера.

Теперь у вас есть 10-минутное окно для остановки postgres, что должно решить вашу текущую проблему. После одного повторного пересоздания у вас будет 10 минут вместо одной.

О, этот парень только что развернул совершенно новый двухконтейнерный экземпляр, а затем восстановил его из резервной копии. Мы точно не будем так делать без веской причины; мне пришлось прибегнуть к этому два месяца назад, чтобы обойти требования по дисковому пространству для обновления до PG13.

Если вы не на PG13, то вам стоит это исправить.

Я бы развернул новый сервер и переехал на него.

Теперь мы это — в итоге было неизбежно! Помимо БД, нам также потребовалось обновиться с устаревшей версии 18.04LTS.

С базой данных такого размера стоит перенести её в отдельный контейнер.

Это значительно ускорит пересборки и упростит для вас всё остальное.

Если есть документация о том, как это сделать без полной пересборки с нуля, то восстановление из резервных копий мы обязательно рассмотрим.

Итак, вы хотите быстро перенести веб-контейнеры и контейнеры данных на отдельные серверы