Привет! У меня возникли две серьёзные проблемы при остановке и последующем запуске Discourse.
Первая проблема
После 2–3 попыток (неважно, через ./launcher stop или через остановку в Portainer) контейнер отказывается запускаться и постоянно зависает с сообщением: rm: cannot remove '/shared/nginx.http.sock': Is a directory. (Я только что заметил, что сокет находится не в директории shared, а в shared/standalone. Это просто ошибка в сообщении?)
По какой-то пока неизвестной мне причине этот сокет, возможно, после остановки превращается в директорию, и шаблон не может его удалить, так как пытается удалить директорию, а не сокет. Ручное удаление ничего не меняет — он появляется снова каждый раз.
Вторая проблема
Команда ./launcher rebuild app зависает на сообщении FATAL: the database system is starting up после первого предупреждения PANIC could not locate a valid checkpoint record. Я прочитал и перепробовал всё, что нашёл по этой проблеме, и единственное работающее «решение», которое я обнаружил, — это удаление директории Discourse со всем содержимым и повторная настройка всего заново… Очевидно, это не настоящее решение!
Кажется, что иногда остановка контейнера Discourse оставляет базу данных в некорректном состоянии, и она не может продолжить работу, потому что находится в состоянии запуска, возможно, пытаясь что-то исправить. Но я до сих пор не нашёл способа решить эту проблему, которая, похоже, возникает после нескольких циклов остановки и запуска.
Есть какие-нибудь идеи? Возможно ли как-то заставить PostgreSQL самостоятельно исправить эти проблемы?
Нет, это не ошибка. Этот файл находится в томе, который монтируется в контейнере, поэтому пути к нему различаются в зависимости от точки отсчета, то есть внутри контейнера и снаружи него.
Это происходит, когда контейнер не был остановлен корректно. PostgreSQL требует времени для корректного завершения работы, и мы обеспечиваем это при остановке с помощью нашей команды запуска. Однако, если ваш экземпляр достаточно велик или выполняется слишком много транзакций, базе данных может не хватить времени на корректную остановку в рамках отведенного ей срока.
Однако я обнаружил, что файл “nginx.http.sock” также создаётся в директории “shared/standalone” на хостовой файловой системе. Изначально он отображается как сокет (розовый цвет), но через некоторое время, возможно после остановки, превращается в директорию (синий цвет), из-за чего контейнер отказывается запускаться, застревая на попытке удалить сокет, который стал директорией.
Итак, что мы можем сделать, чтобы исправить это? До сих пор я только экспериментировал, но если я выведу систему в онлайн с сотнями подключённых пользователей и сотнями тысяч сообщений, рискну ли я потерять всё только потому, что PostgreSQL не справится с внезапным прерыванием? Придётся ли что-то делать для восстановления повреждённой базы данных? Может ли Discourse работать с внешним PostgreSQL, которым мы сможем управлять, если контейнер Discourse не запустится? Короче говоря, в случае “ПАНИКИ” или “ФАТАЛЬНОЙ ОШИБКИ” должно существовать какое-то решение…
На самом деле пытаюсь решить проблему (на будущее), настроив «контейнеризированный» Postgres и подключив его к Discourse, с надеждой не повредить базу данных (или хотя бы иметь возможность выполнять некоторое обслуживание даже при остановке Discourse) при остановке Discourse.