Discourse travando e restauração do discourse FALHOU

Executei o comando ./launcher rebuild app


redis is now ready to exit, bye bye ... o Discourse fica travado - 40 min, parei com Ctrl + C

Fica carregando o tempo todo. Como resultado, não criamos um novo container. Poderia explicar quais tipos de logs no Discourse podem nos ajudar a encontrar a causa?

Isso poderia ser um problema de alocação de recursos?

Há outros sites ou serviços hospedados neste servidor? Quanto de RAM/CPU está disponível no seu servidor?

recursos do servidor

Isso é normal.

Isso não é. Geralmente, o novo container é iniciado em menos de um minuto após essa mensagem.

E você tentou isso mais de uma vez com o mesmo resultado?

Sim, várias vezes, com o mesmo resultado.

Estava em uma branch 3d050bdaa31633a954758894629c0eb9fea537d0

Quero atualizar para fe71c43c57c0248a8264245cb6ff0dc114da335a

e o Discourse trava !!

production.log

Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH) subscrição falhou, tentando reconectar em 1 segundo. Stack de chamada ["/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:363:in `rescue in establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:344:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:106:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:307:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:105:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:382:in `ensure_connected'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:231:in `block in process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:320:in `logging'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:230:in `process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:139:in `block in call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:293:in `with_socket_timeout'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:138:in `call_loop'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/subscribe.rb:44:in `subscription'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/subscribe.rb:13:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:3468:in `_subscription'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:2301:in `block in subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `block in synchronize'", "/usr/local/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:2300:in `subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:287:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:741:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:689:in `block in new_subscriber_thread'"]
Exceção do Job: Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH)

Exceção do Job: Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH)

Exceção do Job: Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH)

Exceção do Job: Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH)

Exceção do Job: Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH)

Exceção do Job: Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH)

Exceção do Job: Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH)

Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH) subscrição falhou, tentando reconectar em 1 segundo. Stack de chamada ["/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:363:in `rescue in establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:344:in `establish_connection'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:106:in `block in connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:307:in `with_reconnect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:105:in `connect'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:382:in `ensure_connected'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:231:in `block in process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:320:in `logging'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:230:in `process'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis/client.rb:125:in `call'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:915:in `block in get'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `block in synchronize'", "/usr/local/lib/ruby/2.6.0/monitor.rb:235:in `mon_synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:51:in `synchronize'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/redis-4.1.4/lib/redis.rb:914:in `get'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:360:in `process_global_backlog'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:271:in `block in global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus/backends/redis.rb:284:in `global_subscribe'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:741:in `global_subscribe_thread'", "/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/message_bus-3.2.0/lib/message_bus.rb:689:in `block in new_subscriber_thread'"]
Exceção do Job: Erro ao conectar ao Redis em localhost:6379 (Errno::ENETUNREACH)

Criando escopo :visible_groups. Sobrescrevendo o método existente Group.visible_groups.
Criando escopo :visible. Sobrescrevendo o método existente Notification.visible.
Criando escopo :public_posts. Sobrescrevendo o método existente Post.public_posts.
Criando escopo :private_posts. Sobrescrevendo o método existente Post.private_posts.
Criando escopo :open. Sobrescrevendo o método existente Poll.open.
Migrando para CreateDiscourseVotingCategorySettings (20200727220143)
Migrando para CreateDiscourseVotingVotes (20200728222920)
Migrando para CreateDiscourseVotingTopicVoteCount (20200729042607)
Criando escopo :visible_groups. Sobrescrevendo o método existente Group.visible_groups.
Criando escopo :visible. Sobrescrevendo o método existente Notification.visible.
Criando escopo :public_posts. Sobrescrevendo o método existente Post.public_posts.
Criando escopo :private_posts. Sobrescrevendo o método existente Post.private_posts.
Criando escopo :open. Sobrescrevendo o método existente Poll.open.
Criando escopo :visible_groups. Sobrescrevendo o método existente Group.visible_groups.
Criando escopo :visible. Sobrescrevendo o método existente Notification.visible.
Criando escopo :public_posts. Sobrescrevendo o método existente Post.public_posts.
Criando escopo :private_posts. Sobrescrevendo o método existente Post.private_posts.
Criando escopo :open. Sobrescrevendo o método existente Poll.open.

O Ubuntu 14.04 parece bastante antigo. Nas últimas semanas, vi alguns posts onde isso tem sido um problema:
https://meta.discourse.org/search?q=14.04%20order%3Alatest

Talvez uma atualização em uma dependência entre maio e agora tenha quebrado algo :roll_eyes:

Obrigado pelas respostas

Tenho um novo servidor com Ubuntu 20.04.1 LTS e Docker instalado.

Como posso migrar meu prod-forum antigo para este servidor?
Você poderia sugerir manuais passo a passo para mim?

Construa do zero usando o guia normal. Copie o app.yml. Reconstrua. Importe o arquivo de backup do Discourse do primeiro servidor. Pronto.

(Oh, e uma pequena questão de remapear o IP para o domínio!)

Legal, mas criar backups pelo painel de administração não funciona para nós))

transferir contêiner docker

docker ps -a

docker commit c559bec6f29a local_discourse/app
docker save local_discourse/app > /tmp/local_discourse_app.tar.gz
scp /tmp/local_discourse_app.tar.gz root@meu-novo-servidor:/tmp/
---
docker load < /tmp/local_discourse_app.tar.gz
docker run local_discourse/app

problemas ocorrem nesta etapa - NoMethodError on docker run - #8 by Dev_Work

Você não tem nenhum backup existente fora do local?

Preciso de uma cópia com dados atualizados (sem backups recentes)

Ao restaurar um backup em um novo servidor, ocorrem erros?

./launcher enter app
discourse restore discourse-2020-08-24-103334-v20200811004537.tar.gz

Olá @Dev_Work,

Sinto muito em saber que você está tendo problemas com isso.

Então, para revisar:

  • Você fez um backup manual completo do seu site e esse backup é:
discourse-2020-08-24-103334-v20200811004537.tar.gz
  • Depois, você instalou o Discourse do zero usando o método padrão:
https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md
  • Você fez isso em um servidor Ubuntu 20.04.1 LTS novinho em folha, com o Docker instalado e testado.

  • Em seguida, você restaurou manualmente com o backup acima no novo servidor, certo?

Isso está correto, e é aí que você está agora nessa aventura?

Obrigado pela resposta.
Sim, está correto, um problema surge no novo Ubuntu 20.04.1 LTS.

Você criou um administrador com o nome de usuário “pavel_BLANKEDOUT” antes de tentar o processo de restauração manual do Discourse?

Estou supondo que este não seja o problema, apenas pergunto para cobrir todas as bases, já que o usuário “pavel_BLANKEDOUT” é mencionado no seu erro de chave duplicada.

Não, não foi criado.

O usuário administrador não está no banco de dados de backup.

Olá @Dev_Work

E o seu site original, onde o backup que você está usando está completamente fora do ar?

Ou você consegue acessar o container do seu site antigo e verificar se há um índice corrompido no banco de dados do Discourse?

Além disso, qual versão do PostgreSQL estava sendo executada na sua instância antiga e quebrada? 10 ou 12?

Parece ser o meu problema, Search results for 'could not create unique index category:6' - Discourse Meta

:cry: :frowning:

ERROR:  could not create unique index "index_user_emails_on_email"
DETAIL:  Key (lower(email::text))=(andrii_test@local.com) is duplicated.
EXCEPTION: psql failed: DETAIL:  Key (lower(email::text))=(andrii_test@local.com) is duplicated.
/var/www/discourse/lib/backup_restore/database_restorer.rb:95:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:49:in `run'
script/discourse:143:in `restore'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.6.0/gems/thor-1.0.1/lib/thor/base.rb:485:in `start'
script/discourse:284:in `<top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:63:in `kernel_load'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:476:in `exec'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor.rb:399:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:30:in `dispatch'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/vendor/thor/lib/thor/base.rb:476:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/cli.rb:24:in `start'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:46:in `block in <top (required)>'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/lib/bundler/friendly_errors.rb:123:in `with_friendly_errors'
/usr/local/lib/ruby/gems/2.6.0/gems/bundler-2.1.4/exe/bundle:34:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'

Servidor antigo usava PostgreSQL 12

Site e servidor antigos funcionando

Posso acessar o container do site antigo (como verificar índice corrompido?)