Fórum indisponível devido a erro no Redis nos logs do unicorn (

[AxelTerizaki]

Olá.

Estou hospedando dois fóruns em minha máquina, ambos estão atualizados (3.4.0.beta3-dev para um, e não consigo verificar o que está indisponível).

Um deles foi atualizado no início desta semana e parou de funcionar repentinamente há cerca de 2 dias.

Ao fazer login, uma mensagem “Oops” aparece em todas as páginas.

Entrei no contêiner e olhei os logs do unicorn e parece haver um problema de conexão com o redis:

Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Erro ao buscar trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED)
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Erro ao buscar trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED)
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Erro ao buscar trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED)
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Erro ao buscar trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED)
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Exceção de trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Exceção de trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Exceção de trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Exceção de trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Exceção de trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 3 Exceção de trabalho: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Falha ao relatar erro: Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) 2 Erro ao conectar ao Redis em localhost:6379 (Errno::ECONNREFUSED) falha na assinatura, reconectando em 1 segundo. Pilha de chamadas /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'

O problema é que não vejo o que está errado, pois consigo me conectar ao servidor redis no contêiner via redis-cli e definir e obter chaves normalmente.

Vejo muitas questões semelhantes no fórum, mas elas são antigas ou não tiveram resolução. Alguém pode ajudar? Posso fornecer mais informações se necessário.

[pfaffman (Jay Pfaffman)]

Isso costumava funcionar?

Há quanto tempo você começou?

Você tem duas versões de um arquivo app.yml padrão, cada uma com seu próprio template Redis e postgres e caminhos diferentes para os dados?

Uma possibilidade são as permissões. Em algum momento, o ID do usuário e do grupo usados mudaram, mas nunca vi isso ser um problema em configurações de contêiner único.

[AxelTerizaki]

Obrigado por analisar meu problema.

Sim, isso costumava funcionar até cerca de 3 dias atrás. No entanto, esta manhã tentei executar um backup na CLI de dentro do contêiner e falhou devido a um estranho erro do postgres, então suspeito que o banco de dados esteja corrompido de alguma forma. O que não é relevante para a mensagem de erro que mencionei acima, mas estou inclinado a tentar restaurar um backup funcional de 8 dias atrás (o proprietário do fórum está de acordo) para ver se isso resolve tudo.

Suponho que eu possa restaurar um backup de uma versão mais antiga do Discourse para uma mais nova? (já que houve uma atualização entre o backup e agora.)

EDIT: para esclarecer, os dois fóruns são arquivos yaml diferentes, então cada um tem seu próprio contêiner para trabalhar e diretórios de dados diferentes, obviamente.

[pfaffman (Jay Pfaffman)]

@AxelTerizaki

falhou devido a um erro estranho do postgres

Falhou no backup ou na restauração?

Seria útil se você incluísse o erro estranho, mas se foi na restauração, suspeito que seja o descrito aqui: Restore failing with missing chat_mention function

Se for o caso, meu conselho é esperar. Se esperar não for uma opção, você pode tentar verificar se o site para o qual você está restaurando tem o mesmo commit do site que criou o backup.

[AxelTerizaki]

Está no backup.

pg_dump: error: Falha ao despejar o conteúdo da tabela "posts": PQgetResult() falhou.
pg_dump: error: Mensagem de erro do servidor: ERROR:  could not open file "base/16384/17044": No such file or directory

É por isso que eu disse que tentaria restaurar um backup primeiro para ver se isso resolvia o problema.

[pfaffman (Jay Pfaffman)]

Isso parece um problema de banco de dados.

Você já restaurou um backup do sistema de arquivos antes? Isso parece o tipo de coisa que aconteceria se você fizesse um backup do sistema de arquivos enquanto o banco de dados estivesse em execução. É um dos motivos pelos quais eu não recomendo backups do sistema de arquivos.

Se você quiser restaurar um backup do Discourse, o que eu geralmente recomendaria, você precisaria remover o banco de dados, e criar e migrar um banco de dados vazio antes de fazer a restauração.

[AxelTerizaki]

Eu faço backups do sistema de arquivos, mas excluo bancos de dados postgres, pois os exporto em vez disso. No entanto, posso ter esquecido de excluir a pasta do discourse, terei que verificar isso mais tarde.

As informações em este tópico ainda são válidas para o meu caso de uso?

[pfaffman (Jay Pfaffman)]

O material sobre como obter o backup onde você precisa parece desnecessariamente complicado.

[AxelTerizaki]

Ok, encontrei o culpado, obrigado por me indicar a direção certa sobre o sistema de arquivos. Fizemos uma varredura de vírus e alguém carregou algo no fórum que tinha uma assinatura de vírus. Como resultado, o ClamAV removeu o arquivo. Vou ajustá-lo melhor para que não coloque mais arquivos do postgres em quarentena.

Desculpe pela perda de tempo

[pfaffman (Jay Pfaffman)]

Ótimo! Que bom que minha dica ajudou! Eu nunca teria pensado nisso, mas faz muito tempo que não executo um antivírus.