Multisite ripristina i caricamenti su 'default' invece del nome effettivo del database

Sviluppatore
1

Sull’ultima versione beta di Discourse, installazione Docker, multisito.

Sto tentando di ripristinare un backup con il database originale REDACTED verso il database corrente db8015. Gli upload finiscono in default, sia nel filesystem che nel database.

Ciò accade sia quando il ripristino viene avviato dall’interfaccia grafica, sia quando viene eseguito da riga di comando utilizzando RAILS_DB=db8015 RAILS_ENV=production script/discourse restore.

Durante il processo di ripristino, RailsMultisite::ConnectionManagement.current_db cambia dal database corretto a default. Sono riuscito a individuare il problema in [Rake::Task['db:_dump'].invoke in db.rake](https://github.com/discourse/discourse/blame/master/lib/tasks/db.rake#L59).

Prima di quella riga, RailsMultisite::ConnectionManagement.current_db ha il valore corretto (db8015), dopo quella riga diventa default.

Sembra che questa correzione abbia rotto qualcosa in produzione @sam?

Log:

[INIZIATO]
'DHSupport' ha avviato il ripristino!
Impostazione dello stato di ripristino in corso...
Verifica dell'esistenza di /var/www/discourse/tmp/restores/db8015/2019-10-11-104940...
Copia dell'archivio nella directory tmp...
Decompressione dell'archivio, ciò potrebbe richiedere del tempo...
Nessun file di metadati da estrarre.
Convalida dei metadati...
  Versione corrente: 20191007140446
  Versione ripristinata: 20190908234054
Estrazione del file dump...
Creazione delle funzioni mancanti nello schema discourse_functions
Impossibile ripristinare in uno schema diverso, ripristino in loco
Attivazione della modalità sola lettura...
Pausa di sidekiq...

[eliminato molto materiale irrilevante]

Pulizia della cache dei temi
Estrazione degli upload...
Rimappatura degli upload...
Rimappatura di 'uploads/REDACTED' in 'uploads/default'
Ottimizzazione delle icone del sito...
I post verranno rigenerati da un job in background su sidekiq. Vedrai immagini mancanti fino al completamento dell'operazione.
Puoi accelerare il processo eseguendo manualmente "rake posts:rebake_uncooked_posts"
Esecuzione dell'after_restore_hook...
Pulizia dei file temporanei...
Rimozione della funzione dallo schema discourse_functions
Eliminazione della directory tmp '/var/www/discourse/tmp/restores/db8015/2019-10-11-104940'...
Ripresa di sidekiq...
Impostazione dello stato di ripristino completato...
2

È ancora un problema @sam?

3

Solo per chiarire, la riproducibilità è la seguente:

  • Crea un multisito in un contenitore Docker

  • Esegui il backup di uno dei multisiti

  • In un nuovo contenitore Docker, ripristinalo

  • I file caricati si trovano nel posto sbagliato

@kris.kotlarek, puoi riprodurre questo problema in locale e verificare se riesci a risolverlo?

Sospetto che ci imbatteremo in questo problema in futuro.

6

Solo il container di destinazione deve essere multisito per riprodurre il problema.

  • Crea un forum in un container Docker
  • Crea un backup
  • In un nuovo container Docker multisito, ripristinalo
  • I file caricati si trovano nella posizione errata
7

Ho dedicato del tempo a questo bug e volevo aggiornarti sui miei riscontri. In sostanza, ho confermato tutto ciò che hai già detto: il processo di ripristino è il seguente:

migrate_database
reconnect_database
...
extract_uploads

Il problema è che, dopo l’attività di migrazione, reconnect_database non passa al database desiderato, ma inizia a lavorare su quello predefinito.

Di conseguenza, questo codice è errato:

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

Una soluzione rapida sarebbe utilizzare qui @current_db, che contiene ancora il nome corretto, al posto di RailsMultisite::ConnectionManagement.current_db, ma questo non risolve il vero motivo per cui reconnect_database non funziona correttamente.

Devo approfondire per individuare il problema.

8

Sei sicuro che accada dopo l’attività di migrazione?

Questo codice

  migrate_database
  puts "Dopo la migrazione, prima della riconnessione #{RailsMultisite::ConnectionManagement.current_db}"
  reconnect_database

restituisce:

Ottimizzazione delle icone del sito... Fatto
Dopo la migrazione, prima della riconnessione default
Riconnessione al database...

Ma quando commenti la riga

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

in lib/tasks/db.rake

restituisce:

Ottimizzazione delle icone del sito... Fatto
Dopo la migrazione, prima della riconnessione db8015
Riconnessione al database...
9

Hai ragione. Ho rimosso Rake::Task["db:migrate"].invoke da restorer.rb e ho ottenuto il database corretto durante tutto il processo.
Sei un passo avanti a me; il mio piano ora è entrare nel task di migrate e vedere quale passaggio sta interrompendo il processo.
Grazie per aver segnalato _dump, andrò direttamente lì per vedere cosa sta succedendo all’interno.

10

Ho dedicato del tempo a indagare, ma alla fine ho trovato una soluzione :slight_smile:

11

Grazie!

Dopo averci riflettuto un po’ di più, cosa significa esattamente eseguire db:dump su qualcosa che non è il database principale?

Non dovrebbe semplicemente saltare il comando db:dump se il database non è quello predefinito?

16

La correzione è stata unita, grazie per aver individuato il problema. Il comando dump è stato aggiunto perché c’era un problema con le migrazioni multisito. Credo che non importi quale database stiamo usando per eseguire il dump della struttura, dato che tutti i multisito dovrebbero avere la stessa struttura.