Puoi gentilmente indicarci quale file dobbiamo modificare nel backup tar?
Negli archivi è incluso dump.sql. Devi modificarlo e poi ricomprimerlo nella versione modificata. Ho risolto anche gli altri miei problemi modificandolo: ho rimosso alcuni campi personalizzati errati che causavano crash dopo l’accesso.
Grazie.
Proverò a scaricare il backup, decomprimerlo e modificare quel file seguendo le tue istruzioni.
È piuttosto spaventoso dover fare tutto questo per ripristinare un backup.
Immagino sia un bug della nuova versione.
Tuttavia, il backup e il ripristino sono i pilastri di un piano di disaster recovery.
Dovrebbero essere il più robusti possibile, e un bug in tali processi ha un impatto significativo.
Bene, sono riuscito a eseguire il ripristino senza apportare alcuna modifica al file di backup.
Ho provato diverse volte e, stranamente, in una delle occasioni il ripristino è andato a buon fine senza errori.
Sono stato espulso da Discourse e non funzionava finché non ho creato un’app di rebuild del launcher.
Ma ora funziona correttamente.
Un problema strano.
Questo continua a darmi problemi nel ripristinare il mio forum dal backup. Sono passate diverse settimane e la funzionalità di ripristino dal backup sembra ancora non funzionare.
C’è una soluzione a questo problema?
Per quanto mi risulta, alterno aggiornamenti, controllo della formattazione delle tabelle, assicurandomi che tutto sia coerente tra sorgente e destinazione, e osservo fallimenti multipli; il tutto potrebbe o meno funzionare senza alcune modifiche minori al database.
Ho migrato con successo 2 siti su 3 e sono costretto a dedicargli meno di un’ora al giorno per mantenere la sanità mentale. Ho iniziato a parlare con i clienti dei problemi che questa situazione potrebbe causare in futuro in casi simili. shrug
Insisto semplicemente nel ripristino e sono riuscito a farlo funzionare.
L’errore segnala una colonna che non esiste nella tabella del profilo utente.
Ma dovrebbe trattarsi di un errore di timeout o qualcosa di simile lato database, forse un bug lato PostgreSQL. Se la colonna non esiste, non viene creata automaticamente quando si insiste nel ripristino.
Jaromir afferma che modificare lo script risolve il problema.
Nessuno degli sviluppatori di Discourse qui sembra essersi preoccupato di questo problema, ma è un errore strano e molto preoccupante, poiché incide sul piano di disaster recovery.
Forse l’argomento è passato inosservato tra gli altri.
Non è passato inosservato. Sarà la prima cosa che controllerò domani.
Inoltre, sto iniziando a lavorare sul miglioramento dei backup e dei ripristini, perché nessuno dovrebbe dover preoccuparsi di queste cose in caso di disastro o quando si desidera semplicemente migrare su un nuovo server.
Ottimo. Grazie.
Sono contento di sentirlo.
Grazie, Gerhard. Non so se ti interessi ora, ma sto riscontrando problemi anche con un sito che utilizza PG 11 su GCP. Potrebbe valere la pena verificare la questione, dato che potrebbe influire sul futuro passaggio a PG12, che, come ho capito, dovrebbe avvenire più avanti questo autunno.
Ho appena aggiornato due istanze che condividono lo stesso bucket di backup S3. Ho eseguito un backup su una di esse e ho tentato di ripristinarlo sull’altra, ottenendo:
Nessuna migrazione con il numero di versione 20191007140446.
PostgreSQL 11 e 12 non sono attualmente supportati.
Ok, ho installato l’ultima versione di Discourse (tests-passed) su un droplet e il ripristino dei backup (inclusi gli upload, senza utilizzare S3 per gli upload) è avvenuto senza problemi.
Se continui a riscontrare problemi durante il ripristino, segui questi passaggi:
-
Ricrea il container:
cd /var/discourse git pull ./launcher rebuild app -
Ripristina il backup tramite l’interfaccia web o la riga di comando:
cd /var/discourse ./launcher enter app discourse enable_restore discourse restore <filename>
Se non funziona, pubblica il numero di versione del file di backup che stai cercando di ripristinare, insieme al messaggio di errore visualizzato durante il ripristino.
Entrambi i siti sono alla versione 2.4.0.beta6 (8fc0cc9aaa). I backup (ma non i file caricati) sono su S3.
discourse restore restituisce
Starting restore: wonderful-community-2019-10-10-184822-v20191007140446.tar.gz
[STARTED]
'system' ha avviato il ripristino!
Marcatura del ripristino come in corso...
Verifica dell'esistenza di /var/www/discourse/tmp/restores/default/2019-10-10-211121...
Download dell'archivio nella directory tmp...
Decompressione dell'archivio, potrebbe richiedere del tempo...
EXCEPTION: Compression::Strategy::ExtractFailed
/var/www/discourse/lib/compression/gzip.rb:49:in `block in extract_file'
/var/www/discourse/lib/compression/gzip.rb:45:in `open'
/var/www/discourse/lib/compression/gzip.rb:45:in `extract_file'
Certo, e penso che quel sito si accontenti dei backup diretti del database su GCP, ma a un certo punto Sam ha detto di eseguire PG 11 sul suo sito di sviluppo e che sarebbe stato interessato a conoscere eventuali problemi con PG11.
@pfaffman Aumenta l’impostazione del sito decompressed_file_max_size_mb (è nascosta). Attualmente il valore predefinito è impostato a 1 GB.
Ho pronto un PR per portare il predefinito a 100 GB, ma non è ancora stato unito:
Grazie, @Roman. Bene, così abbiamo risolto quel problema.
Ma ora ho un mucchio di invalid command \N (e hanno riempito il buffer prima che potessi recuperare ciò che li precedeva), ma forse
ERROR: syntax error at or near "Shiny"
LINE 1: Shiny contest submission 2019-01-07 20:00:05.570573 2019-01-...
^
EXCEPTION: psql failed
/var/www/discourse/lib/backup_restore/restorer.rb:324:in `restore_dump'
/var/www/discourse/lib/backup_restore/restorer.rb:75:in `run'
è ciò di cui hai bisogno.
Sì, credo che sia causato da PG11.
Se si trattasse dell’istanza pg11, sarei d’accordo! Ma questa è un’installazione standard con 2 container.
Aspetta! C’è una discrepanza di versione.
root@community:/var/discourse# ./launcher enter data root@staging-data:/# psql --version
psql (PostgreSQL) 10.7 (Ubuntu 10.7-1.pgdg16.04+1)
Quello su cui sto ripristinando è la 10.9! Scommetto che è quello il problema. (Penso che pg11 fallisca in modo simile, ma lì sto cercando di ripristinare sulla stessa istanza).
Domani aggiornerò i container dei dati e farò sapere. Grazie per l’aiuto.
Bene, ho aggiornato entrambi a 10.10 (utilizzando i modelli di dati standard), ma ho comunque ricevuto gli errori di invalid command.
Quando sono iniziati gli errori invalid command, ho forzato la chiusura dello script di ripristino. Ulteriori tentativi di ripristino (per ottenere il primo errore prima dei messaggi invalid command) hanno portato a:
ActiveRecord::StatementInvalid: PG::UndefinedTable: ERROR: relation "theme_fields" does not exist
Ho quindi eseguito rake db:migrate su entrambe le istanze, effettuato di nuovo il backup e il ripristino è riuscito. Forse una migrazione è stata saltata da qualche parte lungo il percorso?
(dopo aver modificato l’impostazione menzionata sopra—ecco le istruzioni complete per chi potrebbe averne bisogno nel brevissimo lasso di tempo prima che diventino inutili)
./launcher enter app
rails c
SiteSetting.decompressed_file_max_size_mb=1000000
Ne ho appena fallito un altro. Entrambi sono alla versione 2.4.0.beta6 (uno è 2c011252f1, l’altro potrebbe essere leggermente più recente).
Sto ripristinando tramite S3. Ho provato sia con che senza i file caricati. Entrambi sembravano funzionare per poi fallire in questo modo:
...
COPY 11871
COPY 3689
COPY 0
COPY 36550
COPY 0
COPY 14736
/usr/local/bin/discourse: riga 2: 3232 Terminato RAILS_ENV=production sudo -H -E -u discourse bundle exec script/discourse "$@"
È questo l’unico messaggio che ricevi?
Cosa succede se provi a rimuovere qualsiasi dipendenza da S3 e a copiare prima il file di backup in locale?
@pfaffman, potrebbe essere utile sapere che i due (o tre) problemi di ripristino che hai segnalato in questo argomento non sono manifestazioni del bug originariamente trattato qui (il problema PG::UndefinedColumn: ERROR). Potresti prendere in considerazione l’idea di aprire nuovi argomenti per questi, poiché si tratta chiaramente di problemi diversi.