Запуск команды “./launcher rebuild app” завершается неудачей на этапе db:migrate. Обратите внимание, что используется PostgreSQL v12.
Это полностью вывело наш форум из строя. Docker-контейнер запустился снова, но форум не работает. К счастью, я сделал снимок виртуальной машины перед обновлением и сейчас восстанавливаю его.
Журнал:
Задачи: TOP => db:migrate
(Полный трассировочный вывод можно получить, запустив задачу с флагом --trace)
I, [2022-04-14T15:20:51.896917 #1] INFO -- : == 20220304162250 EnableUnaccentExtension: миграция ==========================
-- enable_extension("unaccent")
I, [2022-04-14T15:20:51.897218 #1] INFO -- : Завершение асинхронных процессов
I, [2022-04-14T15:20:51.897265 #1] INFO -- : Отправка сигнала INT для HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main pid: 1710
I, [2022-04-14T15:20:51.897396 #1] INFO -- : Отправка сигнала TERM для exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 1827
2022-04-14 15:20:51.897 UTC [1710] LOG: получен запрос на быстрое завершение работы
1827:signal-handler (1649949651) Получен сигнал SIGTERM, планирование завершения работы...
2022-04-14 15:20:51.900 UTC [1710] LOG: прерывание любых активных транзакций
2022-04-14 15:20:51.902 UTC [1710] LOG: фоновый рабочий процесс "logical replication launcher" (PID 1719) завершился с кодом выхода 1
2022-04-14 15:20:51.904 UTC [1714] LOG: завершение работы
1827:M 14 Apr 2022 15:20:51.913 # Пользователь запросил завершение работы...
1827:M 14 Apr 2022 15:20:51.914 * Сохранение финального снимка RDB перед завершением работы.
2022-04-14 15:20:51.965 UTC [1710] LOG: система баз данных завершена
1827:M 14 Apr 2022 15:20:53.157 * База данных сохранена на диск
1827:M 14 Apr 2022 15:20:53.157 # Redis теперь готов к завершению работы, пока...
ОШИБКА
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' завершилась с ошибкой, код возврата #<Process::Status: pid 2118 exit 1>
Место возникновения ошибки: /usr/local/lib/ruby/gems/2.7.0/gems/pups-1.1.1/lib/pups/exec_command.rb:117:in `spawn'
Выполнение завершено с ошибкой с параметрами {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]}
Загрузка не удалась с кодом выхода 1
** НЕ УДАЛОСЬ ЗАПУСТИТЬ ** Пожалуйста, прокрутите вверх и найдите более ранние сообщения об ошибках, их может быть несколько.
./discourse-doctor может помочь диагностировать проблему.
2dcd9aeca614c9e06ef748f673eb68203db6eae5c445253b416d666663879d6d
==================== КОНЕЦ ЖУРНАЛА ПЕРЕЗАПУСКА ====================
Не удалось перезапустить приложение.
Они не разделены, и внешнего PG нет. Обновление до PG13 также не удалось (без разрушения данных, в отличие от сегодняшнего обновления), и, честно говоря, я не получил здесь поддержки по поводу того, как это исправить.
Я полагаю (проверить, конечно, не могу), что у нас отображался только один контейнер в docker ps. Стандартная установка теперь состоит из двух контейнеров?
Это расширение стало доступно как «доверенное» в PostgreSQL 13+, где его может включить любой пользователь.
Поскольку вы используете более старую версию PostgreSQL, вам придётся обойти это ограничение, установив и включив это расширение для пользователя Discourse, а также, возможно, попытавшись обмануть Discourse, заставив его считать, что расширение уже установлено. Либо можно перейти на текущую поддерживаемую версию PostgreSQL.
Хорошо. Итого: вы больше не поддерживаете PG12. Предлагаю разместить это сообщение в теме обновления до PG13, а также, вероятно, в анонсах версии 2.9.0b4.
Если вы беспокоитесь о простое, одним из решений будет репликация сервера на нового хоста. Например, community/archived/setting-up-postgres-hot-standby.md at master · GoogleCloudPlatform/community · GitHub. (Возможно, вы сможете найти более актуальные инструкции или те, которые будут понятнее для вас…). Это позволит вам мигрировать на новую базу данных, пока старая продолжает работать. Однако это далеко не просто.
Это отличная идея, если бы это был MySQL, MS-SQL или Oracle, я бы так и сделал, но учитывая мой недостаток опыта с PostgreSQL, я, вероятно, просто приму простои.
Итак, восстановление наконец завершилось, хотя заняло более 4 часов. При этом Discourse выдавал ошибки 502. Этот снимок был сделан до обновления, так что это невероятно странно.
В любом случае, посмотрев логи nginx, я обнаружил эту ошибку:
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.10.3/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:30:in `require': cannot load such file -- /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb (LoadError)
Действительно, этот файл принадлежал пользователю root:root и имел права chmod 0000. Изменение владельца на discourse:root и прав на 644, чтобы они соответствовали другим файлам в этой директории, позволило системе снова заработать. Уф!
Есть ли идеи, как этот файл мог быть удалён или изменён? Он ещё и имеет размер 0 байт, что очень странно.
root@forum-app:/shared/log/rails# ls -la /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
-rw-r--r-- 1 discourse root 0 Feb 10 17:41 /var/www/discourse/lib/freedom_patches/schema_cache_concurrency.rb
Пытался выполнить «Восстановление до чистой установки», но это не сработало — PostgreSQL не сотрудничает. Пытался понизить версию Discourse и вернуться к PG12, но тогда начинается настоящий карнавал света со всеми плагинами.
Да, я изменил шаблон как часть стратегии «ладно, это не работает», чтобы вернуться к версии PG12 (хотя это заставляет меня задуматься, как же я тогда буду обновлять PG ).
Я пробовал более новые коммиты, но ошибка enable_extension("unaccent") всё ещё сохраняется, что означает, что в этих коммитах изменение зависимости от неё уже было внесено.
Жду результата этой попытки.
Обновление: нет, не получилось — восстановление завершилось неудачей на этапе «распаковки дампа», и теперь всё снова неработоспособно.
Привет! Если у вас есть резервная копия Discourse, я рекомендую сначала попробовать это на другом сервере.
Полагаю, вы столкнулись с этой проблемой при обновлении экземпляра Discourse, который работал на более старой версии.
Попробуйте установить копию Discourse, вручную отредактировав YAML-файл для использования версии Discourse “stable” и зафиксировав версию PostgreSQL 12.
Если сборка пройдет успешно, попробуйте восстановить резервную копию. Надеюсь, восстановление пройдет без ошибок.
Если всё прошло успешно, верните шаблон PostgreSQL 12 обратно к шаблону по умолчанию и закомментируйте тег “stable”, чтобы Discourse пересобрался с последними тестами.
Я считаю, что если резервную копию можно спасти, то после этого она должна выдержать обновления PostgreSQL и Discourse.
Сейчас я как бы в «подвешенном состоянии». Попробовал вашу рекомендацию с PG12 и версией «Stable». Не работает, восстановление просто останавливается. Поэтому я снова очищаю машину, чтобы начать заново, потому что теперь она не может пересобрать приложение.
Пока эта машина пытается «вернуться к PG12», я пытаюсь понять, смогу ли я продвинуться на другой: если я попробую обновить PostgreSQL с помощью чистой установки, она завершается ошибкой после Creating missing functions in the discourse_functions schema... (начинает возвращать 500), а вывод tail -f shared/data/log/var-log/postgres/current показывает, что контейнер с данными «работает», хотя он полон «ошибок», таких как эта:
discourse@discourse ERROR: relation "user_auth_tokens" does not exist at character 34
discourse@discourse STATEMENT: SELECT "user_auth_tokens".* FROM "user_auth_tokens" WHERE ((auth_token = 'XXXX=' OR
prev_auth_token = 'XXXX=') AND rotated_at > '2022-03-09 10:21:44.051357') LIMIT 1
discourse@discourse ERROR: relation "application_requests" does not exist at character 41
discourse@discourse STATEMENT: SELECT "application_requests"."id" FROM "application_requests" WHERE "application_requests"."date" = '2022-05-08' AND "application_requests"."req_type" = 0 LIMIT 1
Однако, возможно, Discourse уже не работает, но машина используется, так что… может быть, всё идёт нормально, просто это занимает часы и часы? Потому что я дал ему поработать больше часа, и ничего не изменилось.
На данном этапе я уже думаю, не стоит ли перенести это сюда, lol.
P.S. Я пробовал 2 разных резервных копии, так как сделал две перед началом этой авантюры.
Это не хорошо — значит, вы не смогли восстановить резервную копию из старой версии Discourse с PG12 на новую с PG13? Можете выложить сообщения об ошибках и прочее? Все здесь многократно уверяли меня, что это сработает.
).