Форум недоступен: ошибка Redis в логах Unicorn (

Поддержка Самостоятельное хостинг
1

Здравствуйте.

Я хостю два форума на своей машине, оба обновлены до последней версии (одна — 3.4.0.beta3-dev, а на другой, которая недоступна, я не могу проверить версию).

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

После входа в систему на каждой странице появляется сообщение «Ой».

Я зашел в контейнер и просмотрел логи unicorn — похоже, возникла проблема с подключением к Redis:

Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 2 Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:379:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:115:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:344:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:114:in `connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:409:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:269:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:356:in `logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:268:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:161:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/mini_profiler/profiling_methods.rb:89:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/commands/strings.rb:191:in `get'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:388:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:277:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:289:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:768:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:739:in `block in new_subscriber_thread'

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

Я вижу множество похожих проблем на форуме, но они либо старые, либо так и не получили решения. Кто-нибудь может помочь? Я могу предоставить дополнительную информацию, если это потребуется.

2

Раньше это работало?

Как давно вы начали?

У вас две версии стандартного файла app.yml, каждая со своим шаблоном Redis и PostgreSQL и разными путями к данным?

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

3

Спасибо, что уделили время моим вопросам.

Да, это работало нормально примерно до 3 дней назад. Однако сегодня утром я попытался запустить резервное копирование через CLI внутри контейнера, но оно завершилось ошибкой из-за странной ошибки PostgreSQL, поэтому я подозреваю, что база данных каким-то образом повреждена. Это, конечно, никак не связано с сообщением об ошибке, которое я упомянул выше, но я склонен попробовать восстановить рабочую резервную копию за 8 дней (владелец форума согласен на это), чтобы проверить, решит ли это все проблемы.

Предполагаю, можно ли восстановить резервную копию из более старой версии Discourse в новую? (ведь между моментом создания резервной копии и сейчас было обновление.)

РЕДАКТИРОВАНИЕ: для уточнения — оба форума используют разные YAML-файлы, поэтому у каждого свой контейнер и, очевидно, разные директории с данными.

4

Сбой произошел при резервном копировании или при восстановлении?

Было бы полезно, если бы вы привели текст этой странной ошибки, но если проблема возникла при восстановлении, я подозреваю, что речь идет о ситуации, описанной здесь: Restore failing with missing chat_mention function

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

5

Это в резервной копии.

pg_dump: ошибка: не удалось выгрузить содержимое таблицы "posts": PQgetResult() не удался.
pg_dump: ошибка: сообщение об ошибке от сервера: ОШИБКА: не удалось открыть файл "base/16384/17044": Нет такого файла или каталога

Вот почему я сказал, что сначала попробую восстановить резервную копию, чтобы проверить, решит ли это проблему. :slight_smile:

6

Это действительно похоже на проблему с базой данных.

Вы уже восстанавливали резервную копию файловой системы? Это могло произойти, если вы создали резервную копию файловой системы во время работы базы данных. Именно по этой причине я не рекомендую делать резервные копии файловой системы.

Если вы хотите восстановить резервную копию Discourse (что я обычно рекомендую), вам нужно удалить базу данных, создать новую пустую базу данных и выполнить её миграцию перед восстановлением.

7

Я делаю резервные копии файловой системы, но исключаю базы данных PostgreSQL, так как делаю их дамп отдельно. Однако, возможно, я забыл исключить папку Discourse — мне нужно будет это проверить позже.

Актуальна ли информация в этой теме для моего случая?

8

Инструкция о том, как получить резервную копию в нужном месте, кажется излишне запутанной.

9

Отлично, я нашел виновника. Спасибо, что указали правильное направление в отношении файловой системы. Мы запускаем сканирование на вирусы, и кто-то загрузил на форум файл с сигнатурой вируса. В результате ClamAV удалил этот файл. Я настрою его лучше, чтобы он больше не помещал файлы PostgreSQL в карантин.

Извините за потраченное время :slight_smile:

10

Отлично! Рад, что мой совет помог! Я бы и не подумал об этом, но я уже очень давно не использую антивирусное ПО.