Processo di ripristino annullato durante la migrazione dei caricamenti a S3

Supporto
1

Ho riscontrato dei problemi tentando di eseguire un ripristino sulla nostra istanza di Staging di Discourse. Staging sta eseguendo v2.4.0.beta1 +36. Avete idea di dove possa essersi verificato l’interruzione o dove guardare? Grazie in anticipo!

Di seguito la fine dell’output del 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] Migrazione del database in corso...
[2019-07-16 20:08:16] Riconnessione al database in corso...
[2019-07-16 20:08:16] Ricaricamento delle impostazioni del sito in corso...
[2019-07-16 20:08:16] Disattivazione delle email in uscita per gli utenti non staff in corso...
[2019-07-16 20:08:16] Svuotamento della cache delle emoji in corso...
[2019-07-16 20:08:16] Disattivazione della modalità di sola lettura in corso...
[2019-07-16 20:08:16] Svuotamento della cache dei temi
[2019-07-16 20:08:22] Estrazione degli allegati in corso...
[2019-07-16 20:08:40] Migrazione degli allegati su S3 in corso...
[2019-07-16 20:08:46] Il processo di ripristino è stato annullato!
[2019-07-16 20:08:46] Tentativo di rollback in corso...
[2019-07-16 20:08:46] Esecuzione del rollback in corso...
[2019-07-16 20:08:47] Pulizia dei dati in corso...
[2019-07-16 20:08:47] Rimozione della directory tmp '/var/www/discourse/tmp/restores/default/2019-07-16-200516' in corso...
[2019-07-16 20:08:48] Ripresa di sidekiq in corso...
[2019-07-16 20:08:48] Segnalazione del ripristino come completato...
2

C’è qualcosa che non va nella tua configurazione S3?

3

Vedi più output eseguendo discourse restore BACKUP_FILENAME da riga di comando?

4

Controllerò questo e farò rapporto. Grazie.

5

Di seguito è riportato l’output dopo l’esecuzione di discourse restore NOME_FILE_BACKUP dalla riga di comando. Ogni feedback è apprezzato, grazie!

Disattivazione delle email in uscita per gli utenti non staff...

Pulizia della cache delle emoji...

Disattivazione della modalità di sola lettura...

Pulizia della cache del tema

Estrazione dei file caricati...

Migrazione dei file caricati su S3...

Verifica se il database predefinito è già stato migrato...

524 su 9474 file caricati non sono stati migrati su S3. La migrazione su S3 è fallita per il database 'default'.

321 post non sono stati rimappati al nuovo URL di caricamento S3. La migrazione su S3 è fallita per il database 'default'.

Ricerca dei file caricati mancanti su: default

Correzione dei file caricati mancanti: 

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

Mancano 116 file caricati dai post.

Mancano 116 file caricati.

106 su 116 sono file caricati con lo schema precedente.

98 su 83342 post sono interessati.

rake posts:missing_uploads ha identificato 98 problemi. La migrazione su S3 è fallita per il database 'default'.

Nessun post richiede una ricottura

Migrazione dei file caricati su S3 per 'default'...

Alcuni file caricati non sono stati migrati al nuovo schema. Esegui questi comandi nella console di Rails

SiteSetting.migrate_to_new_scheme = true

Jobs::MigrateUploadScheme.new.execute(nil)

Il processo di ripristino è stato annullato!

Tentativo di rollback...

Esecuzione del rollback...

Pulizia dei dati...

Rimozione della directory tmp '/var/www/discourse/tmp/restores/default/2019-07-22-172918'...

Ripresa di sidekiq...

Segnalazione del completamento del ripristino...

Notifica a 'system' della fine del ripristino...

Completato!

[FAILED]

Ripristino completato.
6

È un problema noto. Lo sistemerò domani.

8

Faccio seguito a questa questione per verificare se la correzione è stata implementata? Grazie!

9

No, non è ancora stato risolto. Tuttavia, come soluzione temporanea, puoi disabilitare temporaneamente l’impostazione del sito enable_s3_uploads prima di creare il backup.

10

Aggiornamento sulla soluzione a lungo termine per questa sfida. Grazie!

11

È mai stato risolto? Sto riscontrando lo stesso problema mentre provo a migrare su un nuovo server. Proverò con l’alternativa.

12

Questo mi ha appena dato un morso per una migrazione relativamente grande.

13

Sono quasi sicuro di aver appena incrociato anche io questo problema; credo che debba essere segnalato come un bug.
(Se è diverso, sentiti libero di spostarlo in un nuovo argomento separato)

È piuttosto importante che il ripristino dei backup funzioni.

Nota che la causa del fallimento non è evidente quando si utilizza l’interfaccia di amministrazione e si clicca su Ripristina accanto al nome del backup; si ottiene:

...
Migrazione degli upload verso S3 in corso...
Il processo di ripristino è stato annullato!
...

Completando il ripristino tramite riga di comando si ottengono maggiori dettagli:

discourse enter app
discourse restore example-net-2020-01-02-033557-v20191219112000.tar.gz
...
Riconnessione al database in corso...
Ricaricamento delle impostazioni del sito...
Disabilitazione delle email in uscita per gli utenti non staff...
Pulizia della cache delle emoji...
Disabilitazione della modalità di sola lettura...
Pulizia della cache dei temi
Estrazione degli upload in corso...
Rimappatura degli upload in corso...
Rimappatura di '//forum-example-net.s3.dualstack.eu-west-2.amazonaws.com/' in '/uploads/default/'
optimized_images=3
uploads=1
Migrazione degli upload verso S3 in corso...
Verifica se 'default' è già stato migrato...
6 di 12 upload non sono stati migrati su S3. La migrazione S3 è fallita per il db 'default'.
1 post non sono stati rimappati al nuovo URL di upload S3. La migrazione S3 è fallita per il db 'default'.
Ricerca di upload mancanti su: default

0 upload di post sono mancanti.
  Si prega di fornire le seguenti variabili d'ambiente
    - DISCOURSE_S3_BUCKET
    - DISCOURSE_S3_REGION
    e una delle seguenti
    - DISCOURSE_S3_ACCESS_KEY_ID
    - DISCOURSE_S3_SECRET_ACCESS_KEY
    oppure
    - DISCOURSE_S3_USE_IAM_PROFILE
Il processo di ripristino è stato annullato!
Tentativo di rollback in corso...
Rollback in corso...
Pulizia dei file temporanei in corso...
Rimozione della funzione dallo schema discourse_functions
Rimozione della directory tmp '/var/www/discourse/tmp/restores/default/2020-01-06-222212'...
Riattivazione di sidekiq in corso...
Segnalazione del completamento del ripristino...
Notifica dell'evento 'system' alla fine del ripristino in corso...
Completato!
[FAILED]
Ripristino terminato.

Ho aggiunto un po’ di codice di debug in uploads.rake subito prima di “Si prega di fornire le seguenti variabili d’ambiente” per stampare le variabili d’ambiente:

puts "ENV: " + ENV.inspect

ENV non conteneva alcuna variabile DISCOURSE_S3_* impostata.

Esiste una ragione valida per cui questi dati non vengono recuperati dalle impostazioni?

14

Penso che l’idea sia che, se hai file caricati su S3, eseguirai un backup solo del database e questo non fallirà perché non conterrà i file caricati.

15

Assolutamente, ma questo non aiuta quando il backup che hai include gli upload.

Per essere chiari: al momento non è fondamentale per me, posso commentare le righe problematiche e completare il ripristino, ma gli altri non possono farlo.

16

Concordo. Inoltre, spostare tutti i file caricati su S3 è un compito piuttosto complesso e richiede una CDN S3.

17

Non c’è bisogno di convertirlo in un bug. È già nelle mie priorità e ho già dedicato molto tempo a rifattorizzare il processo di ripristino, aggiungendo numerosi test e rendendolo più affidabile. Farò ancora qualche modifica per rendere il ripristino su S3 meno soggetto a errori e per visualizzare più informazioni nell’interfaccia di amministrazione.

18

Per quanto ne so, il backup/ripristino è stato ripensato, ma ho appena scoperto che questo è ancora un problema.
Un tentativo su beta11 di ripristinare un backup con enable s3 uploads abilitato fallisce ancora con

[2020-02-18 09:51:38] Ripristino dei caricamenti, ciò potrebbe richiedere del tempo...
[2020-02-18 09:51:38] ECCEZIONE: Fornisci le seguenti variabili d'ambiente:
  - DISCOURSE_S3_BUCKET
  - DISCOURSE_S3_REGION
  e una delle seguenti:
  - DISCOURSE_S3_ACCESS_KEY_ID
  - DISCOURSE_S3_SECRET_ACCESS_KEY
  oppure
  - 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

Quindi gli upload su S3 sono abilitati nel database, ma non i backup su S3?

20

Corretto, si tratta della migrazione dei caricamenti.

Le credenziali di accesso S3 sono presenti nel database ripristinato, quindi non è necessario richiederle anche come variabili d’ambiente.

La fornitura delle variabili d’ambiente provoca anch’essa un errore:

Ripristino dei caricamenti, potrebbe richiedere del tempo...
Verifica se db8015 è già stato migrato...
200 su 206 caricamenti non sono stati migrati su S3. Migrazione S3 fallita per il db 'db8015'.
5 post non sono stati rimappati al nuovo URL di caricamento S3. Migrazione S3 fallita per il db 'db8015'.
Nessun post richiede una ricottura (rebake).
Migrazione dei caricamenti su S3 per 'db8015'...
Caricamento dei file su S3...
 - Elenco dei file locali
 => 21 file
 - Elenco dei file S3
. => 16 file
 - Sincronizzazione dei file su S3
.....................
Aggiornamento degli URL nel database...
Rimozione delle immagini ottimizzate vecchie...
Segnalazione di tutti i post contenenti lightbox per la ricottura...
5 post sono stati segnalati per una ricottura
ECCEZIONE: 183 su 206 caricamenti non sono stati migrati su S3. Migrazione S3 fallita per il db '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'

Non ho idea del motivo per cui questo stia fallendo.

La maggior parte dei caricamenti era già su S3, quindi “200 su 206 caricamenti non sono stati migrati su S3” e “183 su 206 caricamenti non sono stati migrati su S3” sono errati. Il numero di 21 file locali è corretto, e ci sono circa 200 caricamenti su S3 (potrebbero essere anche 206). Non riconosco nessuno degli altri numeri (183, 16).

Non ho idea del motivo per cui il processo di ripristino stia cercando di spostare altri caricamenti su S3? Dovrebbe semplicemente prendere le immagini locali dal backup e lasciare i caricamenti su S3 così come sono? O sto trascurando qualcosa?

Alla fine ho finito per modificare manualmente l’impostazione enable_s3_uploads nel dump del database impostandola su false, ma questo ha causato la rimappatura di tutto verso l’archiviazione locale. Dato che c’erano ancora alcune immagini locali, è stato necessario molto lavoro per capire quali dovevano essere rimappate su S3 e quali no.

Tutto ciò avviene su 2.4.0 beta11.

21

La combinazione di upload locali con quelli archiviati su S3 non è supportata. Sì, lo sappiamo, è possibile ritrovarsi in una situazione del genere quando qualcuno passa da locale a S3 senza migrare gli upload esistenti su S3, ma questa è un’altra storia…

Il ripristino di un backup include sempre la rimappatura degli upload se il sistema rileva modifiche che influenzano gli URL degli upload. Questo include il passaggio da standalone a multisito, il passaggio da upload locali a S3, nonché le modifiche alle impostazioni di S3 e CDN. Tutti gli upload vengono ripristinati nella posizione corretta in base alle impostazioni, sia localmente che su S3.

Di tanto in tanto ci imbattiamo in backup in cui la rimappatura automatica e la migrazione su S3 falliscono per vari motivi. Ci si può aspettare di vedere ulteriori miglioramenti all’inizio del ciclo di sviluppo della versione 2.5.