В настройке с несколькими узлами, когда контейнер web_only находится за балансировщиком нагрузки, мы заметили, что некоторые изменения применяются только на одном узле (вероятно, на том, к которому мы были подключены через балансировщик в момент внесения изменений). В частности, это касается: Глобального уведомления, Глобально закрепленных постов и, на данный момент, последнего случая — при смене темы для обновления пользовательской версии.
В результате изменения отображаются у пользователей только в том случае, если балансировщик нагрузки направляет их на тот же узел, где они были внесены. Это приводит к смешанной загрузке страниц и некорректному отображению сайта в некоторых случаях.
Вопрос: нужно ли выполнять какую-либо команду перезагрузки конфигурации через Rake на всех узлах после таких изменений или, возможно, необходимо добавить специальную переменную окружения при запуске контейнера для автоматического обновления/работы в кластерном режиме, чтобы конфигурация автоматически распространялась на соседние узлы?
Или, если вы хотите зайти в консоль Rails, команда SiteSetting.refresh!, скорее всего, сделает то же самое, но она более специфична для настроек сайта.
Спасибо! У меня было предчувствие, что я что-то упустил. Есть ли, возможно, какие-то статьи документации, в которых указано, после каких изменений конфигурации требуются такие действия? Я быстро просмотрел статьи документации, но не заметил ничего подобного, ни для HA-настроек в частности.
Редактирование: похоже, что команда cache:clear недоступна.
docker exec -it web_only bash
root@discourse-build-web-only:/# cd /var/www/discourse
root@discourse-build-web-only:/var/www/discourse# su discourse -c 'bundle exec rake cache:clear'
rake aborted!
Don't know how to build task 'cache:clear' (See the list of available tasks with `rake --tasks`)
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rake-13.3.0/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:25:in `load'
/usr/local/bin/bundle:25:in `<main>'
(See full trace by running task with --trace)
При проверке с помощью флага --tasks я тоже не вижу её в списке.
Просто уточняю: есть ли у вас общая база данных Redis для всех узлов? Это необходимо для работы Discourse.
(некоторые другие приложения работают по схеме один Redis на узел, но попытка использовать такой подход с Discourse приведет к проблемам, которые вы описываете)
Да. Redis используется всеми экземплярами узлов Discourse. Я настроил систему так, чтобы она была отказоустойчивой, поэтому используются отдельные сервисы S3, Redis и PostgreSQL.
Замечаете ли вы какие-либо сообщения об ошибках, подобные «Global messages on xx timed out, message bus is no longer functioning correctly», в директории /logs?
Ранее я обнаружил, что когда Redis и шина сообщений работают на разных хостах, возникают таймауты, что приводит к сбою синхронизации между различными воркерами Unicorn.
Моим решением было периодически перезагружать весь сервер Unicorn.
Ах, вот оно что. В конце концов, там были сообщения Global messages on xx timed out, message bus is no longer functioning correctly. Но я ошибочно смотрел в реальную директорию логов. Теперь, когда я посмотрел в раздел ошибок логов веб-интерфейса, я действительно заметил записи, о которых вы упоминали. Нужно привыкнуть к тому, что в Discourse разные ошибки отображаются в разных местах. Всё же приятно, что в веб-части Discourse есть такие функции.
Этот PR решает проблему Сообщения глобального уровня на xx истекли по времени и устраняет необходимость в обходном пути @pangbo для периодической перезагрузки всего сервера Unicorn.