Processo de restauração cancelado na etapa de migração de uploads para o S3

Suporte
1

Tenho enfrentado problemas ao tentar executar uma restauração na nossa instância de Staging do Discourse. O Staging está rodando v2.4.0.beta1 +36. Alguma ideia de onde pode estar o problema ou onde procurar? Obrigado antecipadamente!

Abaixo está o final da saída do log:

[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] ALTER TABLE
[2019-07-16 20:08:12] Migrando o banco de dados...
[2019-07-16 20:08:16] Reconectando ao banco de dados...
[2019-07-16 20:08:16] Recarregando as configurações do site...
[2019-07-16 20:08:16] Desativando e-mails de saída para usuários não administradores...
[2019-07-16 20:08:16] Limpando o cache de emojis...
[2019-07-16 20:08:16] Desativando o modo somente leitura...
[2019-07-16 20:08:16] Limpando o cache do tema
[2019-07-16 20:08:22] Extraindo uploads...
[2019-07-16 20:08:40] Migrando uploads para o S3...
[2019-07-16 20:08:46] Processo de restauração cancelado!
[2019-07-16 20:08:46] Tentando reverter...
[2019-07-16 20:08:46] Revertendo...
[2019-07-16 20:08:47] Limpando arquivos...
[2019-07-16 20:08:47] Removendo o diretório temporário '/var/www/discourse/tmp/restores/default/2019-07-16-200516'...
[2019-07-16 20:08:48] Retomando o sidekiq...
[2019-07-16 20:08:48] Marcando a restauração como concluída...
2

Há algo de errado com sua configuração do S3?

3

Você vê mais saída ao executar discourse restore BACKUP_FILENAME no terminal?

4

Vou verificar isso a seguir e retorno com um relato. Obrigado.

5

Abaixo está a saída após executar discourse restore NOME_DO_BACKUP na linha de comando. Qualquer feedback é bem-vindo, obrigado!

Desativando e-mails de saída para usuários não membros da equipe...

Limpando cache de emojis...

Desativando modo somente leitura...

Limpando cache do tema

Extraindo uploads...

Migrando uploads para S3...

Verificando se o padrão já foi migrado...

524 de 9474 uploads não foram migrados para S3. A migração para S3 falhou para o banco de dados 'default'.

321 posts não foram remapeados para o novo URL de upload S3. A migração para S3 falhou para o banco de dados 'default'.

Procurando uploads ausentes em: default

Corrigindo uploads ausentes:

..........................................................................................................

116 uploads de posts estão ausentes.

116 uploads estão ausentes.

106 dos 116 são uploads do esquema antigo.

98 dos 83342 posts foram afetados.

rake posts:missing_uploads identificou 98 problemas. A migração para S3 falhou para o banco de dados 'default'.

Nenhum post requer rebaking

Migrando uploads para S3 para 'default'...

Alguns uploads não foram migrados para o novo esquema. Por favor, execute estes comandos no console do rails

SiteSetting.migrate_to_new_scheme = true

Jobs::MigrateUploadScheme.new.execute(nil)

O processo de restauração foi cancelado!

Tentando reverter...

Revertendo...

Limpando coisas...

Removendo diretório tmp '/var/www/discourse/tmp/restores/default/2019-07-22-172918'...

Retomando sidekiq...

Marcando restauração como concluída...

Notificando 'system' sobre o fim da restauração...

Concluído!

[FALHA]

Restauração concluída.
6

Esse é um problema conhecido. Vou corrigi-lo amanhã.

8

Acompanhando este ponto para verificar se a correção foi implementada? Obrigado!

9

Não, ainda não foi corrigido. Mas, como solução alternativa, você pode desativar temporariamente a configuração do site enable_s3_uploads antes de criar o backup.

10

Acompanhando a solução de longo prazo para este desafio. Obrigado!

11

Isso já foi resolvido? Estou enfrentando o mesmo problema ao tentar migrar para um novo servidor. Vou tentar a solução alternativa.

12

Isso acabou me pegando em uma migração relativamente grande.

13

Tenho quase certeza de que acabei de ser afetado por isso também; acredito que isso deva ser marcado como um bug.
(Se for diferente, sinta-se à vontade para mover para um novo tópico separado)

É meio importante que a restauração de backups funcione.

Note que o motivo da falha não é óbvio ao usar a interface de administração do administrador e clicar em Restaurar ao lado do nome do backup; você recebe:

...
Migrando uploads para o S3...
O processo de restauração foi cancelado!
...

Concluir a restauração via linha de comando fornece mais detalhes:

discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Reconectando ao banco de dados...
Recarregando as configurações do site...
Desativando e-mails de saída para usuários não da equipe...
Limpeza do cache de emojis...
Desativando o modo somente leitura...
Limpeza do cache do tema
Extraindo uploads...
Remapeando uploads...
Remapeando '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' para '/uploads/default/'
optimized_images=3
uploads=1
Migrando uploads para o S3...
Verificando se o padrão já foi migrado...
6 de 12 uploads não foram migrados para o S3. A migração do S3 falhou para o banco de dados 'default'.
1 post não foi remapeado para o novo URL de upload do S3. A migração do S3 falhou para o banco de dados 'default'.
Procurando por uploads ausentes em: default

0 uploads de post estão ausentes.
  Por favor, forneça as seguintes variáveis de ambiente
    - DISCOURSE_S3_BUCKET
    - DISCOURSE_S3_REGION
    e qualquer um dos seguintes:
    - DISCOURSE_S3_ACCESS_KEY_ID
    - DISCOURSE_S3_SECRET_ACCESS_KEY
    ou
    - DISCOURSE_S3_USE_IAM_PROFILE
O processo de restauração foi cancelado!
Tentando reverter...
Revertendo...
Limpeza de coisas...
Removendo a função do esquema discourse_functions
Removendo o diretório tmp '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
Retomando o sidekiq...
Marcando a restauração como concluída...
Notificando o 'system' sobre o fim da restauração...
Concluído!
[FALHA]
Restauração concluída.

Adicionei um pouco de código de depuração em uploads.rake logo antes de “Por favor, forneça as seguintes variáveis de ambiente” para exibir as variáveis de ambiente:

puts "ENV: " + ENV.inspect

O ENV não continha nenhuma variável DISCOURSE_S3_* definida.

Há alguma razão significativa para isso não estar puxando esses dados das configurações?

14

Acho que a ideia é que, se você tiver uploads no S3, fará apenas um backup do banco de dados e, assim, não haverá falha, pois não incluirá os uploads.

15

Com certeza, mas isso não ajuda quando o backup que você tem é aquele que inclui os uploads.

Para ficar claro — não é criticamente importante para mim agora, posso comentar as linhas problemáticas e concluir a restauração, mas outros não conseguem.

16

Concordo. E mover todos os uploads para o S3 é uma tarefa bastante complicada e exige uma CDN S3.

17

Não é necessário converter isso em um bug. Está sob minha responsabilidade e já dediquei uma grande quantidade de tempo a refatorar o processo de restauração, adicionando muitos testes e tornando-o mais confiável. Farei alguns ajustes adicionais para tornar a restauração no S3 menos propensa a falhas e para exibir mais informações na interface de administração.

18

AFAIK, o backup/restauração foi refeito, mas acabei de descobrir que isso ainda é um problema.
Uma tentativa no beta11 de restaurar um backup com enable s3 uploads ativado ainda falha com:

[2020-02-18 09:51:38] Restaurando uploads, isso pode levar algum tempo...
[2020-02-18 09:51:38] EXCEÇÃO: Por favor, forneça as seguintes variáveis de ambiente:
  - DISCOURSE_S3_BUCKET
  - DISCOURSE_S3_REGION
  e também uma das seguintes:
  - DISCOURSE_S3_ACCESS_KEY_ID
  - DISCOURSE_S3_SECRET_ACCESS_KEY
  ou
  - DISCOURSE_S3_USE_IAM_PROFILE

[2020-02-18 09:51:38] /var/www/discourse/lib/file_store/to_s3_migration.rb:34:in `s3_options_from_env'
19

Então, os uploads para o S3 estão habilitados no banco de dados, mas não os backups para o S3?

20

Correto, isso trata da migração de uploads.

As credenciais de acesso ao S3 estão presentes no banco de dados restaurado, portanto não é necessário exigir que elas também estejam em uma variável de ambiente.

Fornecer as variáveis de ambiente também resulta em falha:

Restaurando uploads, isso pode levar algum tempo...
Verificando se db8015 já foi migrado...
200 de 206 uploads não foram migrados para o S3. Migração para o S3 falhou para o banco de dados 'db8015'.
5 posts não foram remapeados para a nova URL de upload do S3. Migração para o S3 falhou para o banco de dados 'db8015'.
Nenhum post requer rebaking.
Migrando uploads para o S3 para 'db8015'...
Enviando arquivos para o S3...
 - Listando arquivos locais
 => 21 arquivos
 - Listando arquivos no S3
. => 16 arquivos
 - Sincronizando arquivos com o S3
.....................
Atualizando as URLs no banco de dados...
Removendo imagens otimizadas antigas...
Marcando todos os posts contendo lightboxes para rebake...
5 posts foram marcados para rebake
EXCEÇÃO: 183 de 206 uploads não foram migrados para o S3. Migração para o S3 falhou para o banco de dados 'db8015'.
/var/www/discourse/lib/file_store/to_s3_migration.rb:127:in `raise_or_log'
/var/www/discourse/lib/file_store/to_s3_migration.rb:74:in `migration_successful?'
/var/www/discourse/lib/file_store/to_s3_migration.rb:350:in `migrate_to_s3'
/var/www/discourse/lib/file_store/to_s3_migration.rb:61:in `migrate'
/var/www/discourse/lib/file_store/s3_store.rb:203:in `copy_from'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:48:in `restore_uploads'
/var/www/discourse/lib/backup_restore/uploads_restorer.rb:30:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:58:in `run'
script/discourse:143:in `restore'

Não tenho ideia do motivo dessa falha.

A maioria dos uploads já estava no S3, então as mensagens “200 de 206 uploads não foram migrados para o S3” e “183 de 206 uploads não foram migrados para o S3” estão incorretas. O número de 21 arquivos locais está correto, e há aproximadamente 200 uploads no S3 (poderiam ser 206 também). Não reconheço nenhum dos outros números (183, 16).

Também não faço ideia do motivo pelo qual o processo de restauração está tentando mover mais uploads para o S3. Ele deveria apenas pegar as imagens locais do backup e deixar os uploads no S3 intactos? Ou estou passando por cima de algo?

No final, acabei modificando manualmente a configuração enable_s3_uploads no dump do banco de dados para false, mas isso fez com que tudo fosse remapeado de volta para o local. E como havia algumas imagens ainda locais, foi necessário muito trabalho para descobrir quais precisavam ser remapeadas de volta para o S3 e quais não.

Tudo isso na versão 2.4.0 beta11.

21

A mistura de uploads locais com uploads armazenados no S3 não é suportada. Sim, eu sei, é possível acabar nesse estado quando alguém muda de local para S3 e não migra os uploads existentes para o S3, mas essa é outra história…

A restauração de um backup sempre inclui o remapeamento de uploads se o sistema detectar qualquer alteração que afete as URLs de upload. Isso inclui a troca entre standalone e multisite, a troca entre uploads locais e S3, bem como alterações nas configurações do S3 e da CDN. Todos os uploads são restaurados no local correto com base nas configurações, seja localmente ou no S3.

De vez em quando, encontramos backups em que o remapeamento automático e a migração para o S3 falham por vários motivos. Você pode esperar ver mais melhorias no início do ciclo de desenvolvimento 2.5.