Multisite restaura uploads para 'default' em vez do nome real do banco de dados

Dev
1

Na última versão beta do Discourse, instalação via Docker, multisite.

Estou tentando restaurar um backup com o banco de dados original REDACTED para o banco de dados atual db8015. Os uploads acabam sendo salvos em default, tanto no sistema de arquivos quanto no banco de dados.

Isso ocorre tanto quando a restauração é acionada pela interface gráfica quanto quando feita pela linha de comando usando RAILS_DB=db8015 RAILS_ENV=production script/discourse restore.

Durante o processo de restauração, RailsMultisite::ConnectionManagement.current_db muda do banco de dados correto para default. Consegui identificar que isso está relacionado a [Rake::Task['db:_dump'].invoke em db.rake](https://github.com/discourse/discourse/blame/master/lib/tasks/db.rake#L59).

Antes dessa linha, RailsMultisite::ConnectionManagement.current_db tem o valor correto (db8015); após essa linha, passa a ser default.

Parece que essa correção quebrou algo na produção de alguma forma, @sam?

Logs:

[INICIADO]
'DHSupport' iniciou a restauração!
Marcando a restauração como em andamento...
Verificando se /var/www/discourse/tmp/restores/db8015/2019-10-11-104940 existe...
Copiando o arquivo compactado para o diretório tmp...
Descompactando o arquivo, isso pode levar algum tempo...
Nenhum arquivo de metadados para extrair.
Validando metadados...
  Versão atual: 20191007140446
  Versão restaurada: 20190908234054
Extraindo o arquivo dump...
Criando funções ausentes no esquema discourse_functions
Não é possível restaurar em um esquema diferente, restaurando in-place
Ativando o modo somente leitura...
Pausando o sidekiq...

[deletado muito conteúdo irrelevante]

Limpando cache do tema
Extraindo uploads...
Remapeando uploads...
Remapeando 'uploads/REDACTED' para 'uploads/default'
Otimizando ícones do site...
Os posts serão reprocessados por um job em segundo plano no sidekiq. Você verá imagens faltando até que isso seja concluído.
Você pode acelerar o processo executando manualmente "rake posts:rebake_uncooked_posts"
Executando o after_restore_hook...
Limpando arquivos temporários...
Removendo função do esquema discourse_functions
Removendo diretório tmp '/var/www/discourse/tmp/restores/db8015/2019-10-11-104940'...
Retomando o sidekiq...
Marcando a restauração como concluída...
2

Isso ainda é um problema @sam?

3

Apenas para esclarecer, a reprodução é:

  • Criar um multisite em um container Docker

  • Fazer backup de um dos multisites

  • Restaurá-lo em um novo container Docker

  • Os uploads estão no local errado

@kris.kotlarek, você consegue reproduzir isso localmente e verificar se consegue corrigir?

Suspeito que seremos afetados por isso no futuro.

6

Apenas o contêiner de destino precisa ser multisite para reproduzir o problema.

  • Crie um fórum em um contêiner Docker
  • Crie um backup
  • Em um novo contêiner Docker multisite, restaure-o
  • Os uploads estão no local errado
7

Gastei um tempo com esse bug e queria atualizá-lo com minhas descobertas. Basicamente, confirmei tudo o que você já disse: o processo de restauração é assim:

migrate_database
reconnect_database
...
extract_uploads

O problema é que, após a tarefa de migração, o reconnect_database não muda para o banco de dados desejado, mas começa a trabalhar no padrão.

Portanto, este código está errado:

def extract_uploads
  ...
  current_db_name = 
  RailsMultisite::ConnectionManagement.current_db # padrão
  optimized_images_exist = File.exist?(File.join(tmp_uploads_path, 'optimized'))

Uma solução maltrapilha seria usar aqui @current_db, que ainda contém o nome correto, em vez de RailsMultisite::ConnectionManagement.current_db, mas isso não resolve o problema real de por que o reconnect_database não está funcionando corretamente.

Preciso investigar mais a fundo para encontrar o problema.

8

Você tem certeza de que isso está acontecendo depois da tarefa de migração?

Este código

  migrate_database
  puts "Após a migração, antes de reconectar #{RailsMultisite::ConnectionManagement.current_db}"
  reconnect_database

produz a seguinte saída:

Otimizando ícones do site... Concluído
Após a migração, antes de reconectar default
Reconectando ao banco de dados...

Mas quando você comenta a linha

Rake::Task['db:_dump'].invoke

em lib/tasks/db.rake

A saída é:

Otimizando ícones do site... Concluído
Após a migração, antes de reconectar db8015
Reconectando ao banco de dados...
9

Você está certo. Removi Rake::Task["db:migrate"].invoke do restorer.rb e o banco de dados ficou correto durante todo o processo.
Você está um passo à frente de mim; meu plano agora é entrar na tarefa de migrate e ver qual etapa está quebrando o processo.
Obrigado por apontar o _dump. Vou direto lá para ver o que está acontecendo.

10

Eu investi um tempo nisso, mas finalmente encontrei uma solução :slight_smile:

11

Obrigado!

Depois de refletir mais sobre isso, o que significa exatamente quando db:dump é executado em algo que não é o banco de dados principal?

Não deveria simplesmente ignorar o comando db:dump se o banco de dados não for o padrão?

16

Correção foi mesclada, obrigado por identificar esse problema. O comando dump foi adicionado porque havia um problema com as migrações de multisite. Acredito que não importa qual banco de dados estamos usando para exportar a estrutura, pois todos os multisites devem ter a mesma estrutura.