Implosão após atualização 2.7beta7

[BryanV (Bryan Van de ven)]

Olá a todos,

Há vários anos mantemos uma instância do Discourse auto-hospedada em https://discourse.bokeh.org. De modo geral, ela tem sido extremamente estável e exigiu quase nenhum esforço para manutenção. Em particular, a execução de atualizações costuma ser totalmente tranquila, completando-se perfeitamente sem qualquer problema.

No entanto, hoje, após uma atualização para a versão 2.7beta7 (que parecia ter concluído sem problemas), nosso site entrou em colapso completo. Ele funcionou de forma precária por algum tempo, com páginas renderizadas incorretamente e erros no console do JavaScript, mas, após tentar um rollback, a interface do usuário tornou-se completamente não funcional. Ao acessar o droplet, também tentei, sem sucesso:

Reconstrução

./launcher rebuild app

Isso falhou de várias formas em diversas tentativas.

Discourse Doctor

./discourse-doctor

Restauração

./launcher enter app
discourse restore <arquivo de backup>

Isso falhou.

Limpeza

Também tentei fazer uma “limpeza” (wipe) e depois restaurar:

./launcher stop app
./launcher destroy app
rm -r /var/discourse/shared/standalone/

Após isso, consegui, pelo menos, que uma reconstrução fosse bem-sucedida, levando ao estado de “instalação fresca”, ou seja, “Parabéns, você instalou o Discourse!”.

Agora, tentei executar discourse restore novamente, mas isso falhou mais uma vez:

EXCEÇÃO: 1 post não foi remapeado para o novo URL de upload no S3. A migração para o S3 falhou para o banco de dados 'default'. /var/www/discourse/lib/file_store/to_s3_migration.rb:131:in `raise_or_log' /var/www/discourse/lib/file_store/to_s3_migration.rb:86:in `migration_successful?' /var/www/discourse/lib/file_store/to_s3_migration.rb:357:in `migrate_to_s3' /var/www/discourse/lib/file_store/to_s3_migration.rb:65:in `migrate' /var/www/discourse/lib/file_store/s3_store.rb:240:in `copy_from' /var/www/discourse/lib/backup_restore/uploads_restorer.rb:62:in `restore_uploads' /var/www/discourse/lib/backup_restore/uploads_restorer.rb:44:in `restore' /var/www/discourse/lib/backup_restore/restorer.rb:62:in `run' script/discourse:145:in `restore' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/command.rb:27:in `run' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch' /var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.1.0/lib/thor/base.rb:485:in `start' script/discourse:286:in `' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:63:in `load' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:63:in `kernel_load' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli/exec.rb:28:in `run' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:494:in `exec' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:30:in `dispatch' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/cli.rb:24:in `start' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/exe/bundle:49:in `block in ' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors' /usr/local/lib/ruby/gems/2.7.0/gems/bundler-2.2.7/exe/bundle:37:in `' /usr/local/bin/bundle:23:in `load' /usr/local/bin/bundle:23:in `' Tentando fazer rollback... Fazendo rollback... Limpando arquivos... Removendo funções do esquema discourse_functions... Removendo o diretório temporário '/var/www/discourse/tmp/restores/default/2021-04-23-235404'... Marcando a restauração como concluída... Notificando o 'system' sobre o fim da restauração... Concluído! [FALHA]

O que é estranho é que, durante a restauração, o site parecia estar voltando ao normal, com o conteúdo antigo aparecendo. Então, a falha ocorreu e agora nada aparece, as contas sumiram, etc.

Preciso muito de qualquer orientação ou sugestão aqui. Temos backups diários de até uma semana atrás (e mais antigos no Glacier, se necessário). Deletamos uma Categoria não utilizada há alguns dias; isso poderia ser a causa dos problemas? Vou tentar um backup mais antigo para verificar, mas qualquer dica sobre um processo de restauração infalível será muito bem-vinda.

[BryanV (Bryan Van de ven)]

Um backup mais antigo não ajudou. Durante a restauração, as coisas parecem “mais ou menos OK”

Até o final, quando imediatamente aparece isso:

Como observação lateral, o backup não contém as postagens que foram originalmente importadas de uma lista de e-mails, mas que já estão no site Discourse há anos? Tínhamos 24 mil postagens, não 5 mil, antes disso.

[BryanV (Bryan Van de ven)]

Existe uma maneira de reconstruir o aplicativo em uma versão mais antiga do Discourse, por exemplo, na 2.7beta6?

[BryanV (Bryan Van de ven)]

Alternativamente, acho que há literalmente apenas um único post causando algum problema

EXCEÇÃO: 1 post não foi remapeado para a nova URL de upload do S3. A migração do S3 falhou para o banco de dados ‘default’.

É possível encontrar esse post e simplesmente excluí-lo ou removê-lo?

[pfaffman (Jay Pfaffman)]

Você tem imagens no S3?

[BryanV (Bryan Van de ven)]

@pfaffman Sim, temos imagens no S3.

[pfaffman (Jay Pfaffman)]

Hmm. Bem, talvez haja apenas uma postagem com problema? Acho que você precisaria restaurar o banco de dados, corrigi-lo e depois reconstruir o arquivo de backup com o novo banco de dados. Mas é realmente difícil dizer.

[BryanV (Bryan Van de ven)]

Existem instruções em algum lugar sobre como fazer isso? Como posso determinar qual é a postagem quebrada?

Edição: alternativamente, há alguém com experiência que possa ser contratado para prestar serviços?

[Don]

Você tem um backup ou snapshot recente de um droplet que possa restaurar?

[BryanV (Bryan Van de ven)]

Você tem um backup ou snapshot recente de droplet que possa restaurar?

Infelizmente, não. Os backups da DO são apenas semanais, e eu configurei backups diários do Discourse para o S3, mantendo uma semana de backups recentes e um ano no Glacier. Dada minha experiência positiva anterior com várias atualizações do Discourse, pensei que isso seria suficiente e melhor (e eu já havia feito testes de restauração com sucesso antes).

[Benjamin_D (Benjamin Decotte)]

@pfaffman

Em app.yml, descomente

#version: tests-passed

Digamos
version: 94301854938a0b36dd64666fb7a7c8406544a781, que é o commit logo antes do aumento da versão beta.

[BryanV (Bryan Van de ven)]

Bem, na verdade uma atualização. Em um momento de desespero, simplesmente interrompi bruscamente o script de restauração durante a etapa

Sincronizando arquivos com o S3

antes que ele reclamasse sobre o 1 post defeituoso e iniciasse um rollback.

O site voltou e estava acessível no modo de segurança. Desativei o componente de tema “COPIAR E COLAR” para blocos de código que, aparentemente, agora é totalmente incompatível com a versão beta mais recente. Depois disso, o site parece estar, na verdade, majoritariamente funcionando, mesmo sem o modo de segurança. Mas:

• Há alguma ação recomendada para garantir que tudo esteja o mais “limpo” possível? Por exemplo, reenviar ativos para o S3 e “rebake”? Onde estão as melhores e mais atualizadas instruções para isso?

EDIT: pelo que pude verificar, tudo voltou ao normal. Imagens em posts antigos estão sendo carregadas corretamente do S3/CDN. Acredito que minha pergunta agora é: se estamos enviando imagens para o S3, essa opção deve ser desmarcada?

Incluir uploads nos backups agendados. Desativar isso fará backup apenas do banco de dados.

Acho que pensei que marcar essa opção oferecesse uma camada extra de redundância, mas parece que ela é a fonte de todos esses problemas durante a restauração?

[Don]

@BryanV

Incluir uploads nos backups agendados. Desativar isso fará backup apenas do banco de dados.

Na última vez que migrei para outro provedor de hospedagem, também tive problemas com o S3 ao restaurar. Por isso, perguntei sobre isso e a resposta foi sim. Quando você armazena suas imagens no S3, precisa fazer o backup sem os uploads. Apenas o banco de dados. Mas não sei se essa é a solução no seu caso. Se for tentar, crie um snapshot antes.

Você pode ver mais aqui: Restore a backup from the command line - #28

Acabei de testar e funcionou perfeitamente, sem nenhum problema.

[pfaffman (Jay Pfaffman)]

Posso ajudar. Na segunda-feira, ou mais cedo, com pagamento por risco.

Você pode Contact Us - Literate Computing nosso S3 o endereço de e-mail no rodapé da página.

[BryanV (Bryan Van de ven)]

@pfaffman Obrigado! O site parece estar funcionando completamente normalmente agora, mas não recusaria uma verificação rápida / conferência de sanidade quando for conveniente, se você estiver disposto. De qualquer forma, anotei suas informações de contato comerciais para quaisquer emergências futuras.

Aqui está um relatório pós-incidente (retro), caso seja útil para qualquer outra pessoa

---

RESUMO

Após uma atualização (bem-sucedida), um componente de tema não oficial incompatível tornou a interface do usuário (UI) do site quebrada. Isso não era conhecido na época, então o processo de restauração do backup foi iniciado, mas encontrou problemas devido a uma configuração que deixava a desejar.

DETALHES

1. Uma atualização para 2.7beta7 foi iniciada e concluída com sucesso.

2. No entanto, após a atualização, a UI do site ficou severamente comprometida: os corpos das publicações estavam completamente ausentes, a navegação superior (incluindo usuário / login) estava totalmente ausente e o console de JS relatou erros.

   1. O motivo disso acabou sendo um componente de tema de terceiros incompatível para copiar e colar blocos de código, mas isso não era conhecido na época.

   2. Também não era conhecido na época a possibilidade de entrar no modo de segurança. Se isso fosse conhecido, os problemas restantes poderiam ter sido evitados.

3. O acesso foi obtido a \admin por navegação direta, e uma tentativa de reversão foi iniciada. Isso imediatamente desconectou o usuário, e não parecia haver nenhuma maneira de fazer login novamente com a UI quebrada.

4. Fiz login no Droplet da DO para iniciar uma restauração manual com o último arquivo tarball de backup do S3.

5. Muitas tentativas de restauração falharam perto do passo final, após o upload de ativos do S3, devido a um erro em uma única publicação.

   1. Isso é evidência de que restaurações que tentam reenviar ativos para o S3 podem ser instáveis (vários relatos disso no Meta).
   2. No entanto, não era necessário fazer backup dos ativos de upload, pois eles já estão armazenados no S3!

6. Durante uma das muitas tentativas de restauração, o site também foi apagado para tentar começar do zero, de modo que as reversões após as falhas de restauração agora voltaram para um site vazio.

7. Eventualmente, em um jogo de azar desesperado, executei a restauração e abortei manualmente o script durante o upload para o S3 (logo antes da falha e da reversão).

8. O site voltou online, mas exibiu os problemas anteriores de UI. No entanto, o modo de segurança agora era conhecido e utilizado, e o site funcionava normalmente com plugins e temas desativados.

9. Todos os plugins e temas não oficiais foram removidos (incluindo o componente de “copiar e colar”), após o que o site funcionou normalmente.

10. Verifiquei que as imagens carregadas anteriormente ainda estavam sendo exibidas, vindas do CDN do S3.

Suspeito que o upload final e o “rebake” não foram necessários, já que os ativos ainda estavam no S3 e as publicações não precisavam ser atualizadas para usar novos URLs.

Não tenho certeza de quais etapas de restauração restantes, se houver, foram perdidas após a interrupção do script, mas até agora ninguém encontrou problemas com o site em seu estado atual.

LIÇÕES / AÇÕES

• Comece com o modo de segurança para diagnosticar problemas no futuro.
• Desative a configuração para incluir uploads nos backups (sugerirei ao Discourse que avise sobre essa situação).
• Remova todos os plugins e componentes de tema não oficiais.
• Sugira ativar o novo recurso de copiar blocos de código integrado.
• Ative os backups semanais de imagem do Digital Ocean como uma rede de segurança para recuperação.

[merefield (Robert)]

@BryanV

um componente de tema não oficial incompatível

Componente de Tema ou Plugin? Você poderia informar ao autor?

[BryanV (Bryan Van de ven)]

@merefield Parece ser algo conhecido, foi assim que tomei conhecimento dessa possibilidade

https://meta.discourse.org/t/copy-option-for-code-blocks-in-discourse/60961

[BryanV (Bryan Van de ven)]

Se eu pudesse fazer uma sugestão sobre o processo de restauração, seria oferecer algumas opções para torná-lo mais resiliente. Por exemplo, se o único obstáculo para uma restauração bem-sucedida for um único post com erro, eu apertaria a tecla Y em um piscar de olhos se me perguntassem: ‘Excluir o post com erro?’

[gerhard (Gerhard Schlager)]

Isso estará disponível em uma das próximas betas da versão 2.8. Infelizmente, ainda não está pronto para a próxima versão 2.7.

Desculpe não ter visto seu pedido de ajuda mais cedo. Aqui vai uma dica para todos os demais que enfrentam problemas com restaurações devido a uploads armazenados no S3: Extraia o arquivo dump.sql.gz do seu backup e renomeie-o. Por exemplo, se o backup original era discourse-2020-10-09-133921-v20201007124955.tar.gz, o arquivo resultante deve ser chamado discourse-2020-10-09-133921-v20201007124955.sql.gz. A restauração desse arquivo deve funcionar.