Modificare il database in un backup per rimuovere un tag chiave duplicata ed evitare fallimenti nel ripristino.

Questo post è una versione molto condensata delle mie ultime 24 ore, anche se in realtà non ha ancora funzionato, quindi spero anche che qualcuno pubblichi dove è andato storto qui sotto.

Il mio aggiornamento di Discourse è fallito a causa di una chiave duplicata, uno dei miei tag è raddoppiato. Per risolvere il problema dell’aggiornamento, ho dovuto eseguire una nuova installazione di Discourse e quindi caricare il mio ultimo backup, ma il ricaricamento fallisce perché si arrabbia per la chiave duplicata. Quindi ho dovuto entrare nel backup per modificare il tag incriminato in qualcos’altro.

Per qualche motivo, il backup ri-zippato con il problema del tag duplicato risolto è significativamente più piccolo del backup da cui proviene, e fallisce quando provo a ripristinarlo, quindi qualcosa è andato storto con il processo di rizippatura.

1) Individuazione dei backup: Per individuare i tuoi backup di Discourse, puoi usare il seguente comando:

sudo find / -name "*.tar.gz"

Questo cercherà nel tuo sistema tutti i file di backup con estensione “.tar.gz”. Per impostazione predefinita dovrebbe trovarsi all’interno del tuo container in: shared/backups/default

2) Creazione di una copia: Una volta trovato il backup con cui vuoi lavorare, creane una copia per assicurarti di avere un backup del file originale. Usa il comando “cp”:

bash

sudo cp /path/to/original_backup.tar.gz /path/to/copy_backup.tar.gz

3) Estrazione della copia: Estrai il contenuto del file di backup copiato usando il comando “tar”:

bash

tar -xzvf /path/to/copy_backup.tar.gz

Questo estrarrà i file di backup in una directory temporanea.

4) Modifica dei tag nel database: Naviga nei file di backup estratti e apri il file di database pertinente usando un editor di testo. Ho riscontrato un problema con i tag duplicati “socialmedia”, che hanno impedito un ripristino riuscito. In un database di grandi dimensioni ci sono molte istanze di tag, e probabilmente per il tag specifico che stai cercando, quindi ho cercato ‘immutable socialmedia’ usando Ctrl W in Nano che mi ha portato proprio lì.

sudo nano /path/to/extracted_database.sql

Ho modificato un’istanza del tag “socialmedia” in “socialmedia2”, quindi ho fatto una rapida ricerca per verificare che ora appaia solo una volta. Posso correggere quei tag dalla sezione admin una volta che il ripristino ha successo.

5) Rizippatura: Dopo aver modificato i file di backup, crea un nuovo file di backup con il contenuto corretto. Usa il seguente comando per comprimere i file modificati:

tar -czvf /path/to/new_modified_backup.tar.gz /path/to/modified_files_directory

6) Spostamento nel file corretto: Sposta il nuovo file di backup modificato nella directory appropriata dove vengono archiviati i backup. La posizione predefinita è solitamente “/shared/backups/default”:

sudo mv /path/to/new_modified_backup.tar.gz /shared/backups/default/

7) Arresto e avvio dei servizi: Prima di ripristinare il backup modificato, assicurati di arrestare i servizi pertinenti per evitare potenziali conflitti durante il processo di ripristino. Usa il comando “./launcher stop app” per arrestare l’applicazione Discourse:

./launcher stop app

8) Ripristino del backup: Per ripristinare dal backup modificato, usa il comando “discourse restore” con il percorso del nuovo file di backup:

discourse restore /shared/backups/default/new_modified_backup.tar.gz

Oppure puoi farlo tramite /admin sul tuo sito, poiché ora dovrebbe apparire nella sezione dei backup.

9) Verifica del ripristino: Dopo che il processo di ripristino è stato completato, ho verificato che le modifiche fossero andate a buon fine controllando l’applicazione e il database di Discourse per assicurarmi che i tag duplicati “socialmedia” fossero stati rimossi.

10) Avvio dei servizi: Ho riavviato i servizi che erano stati arrestati in precedenza per riportare online l’applicazione Discourse. Ho usato il comando “./launcher start app” per avviare l’applicazione Discourse:

./launcher start app

11) Eliminazione dei file temporanei e dei backup aggiuntivi: Dopo aver ripristinato con successo il backup, ho eliminato tutti i file temporanei e i backup aggiuntivi creati durante il processo per liberare spazio su disco. Usa il comando “rm” per rimuovere i file:

sudo rm -r /path/to/temporary_directory
sudo rm /path/to/copy_backup.tar.gz
3 Mi Piace

Perché?

Perché non hai potuto risolvere questo problema “online” riavviando l’app, entrando nel container, entrando in postgres e quindi gestendo immediatamente l’inserimento dei dati?

1 Mi Piace

Non mi aspettavo l’errore, quindi avevo già messo la nuova versione di Discourse sul mio server. L’errore di chiave duplicata era nel backup e non nell’app installata pulita, ma non potevo ripristinare il backup perché voleva che l’errore fosse risolto prima.

Quindi ho dovuto provare a modificare il tag all’interno del backup.

Ma hai visto l’errore nell’aggiornamento?

La prossima volta renditi la vita più facile e correggi sul posto.

L’app non era in esecuzione e non potevo ricaricarla, quindi ho aggiornato a una versione fresca di Discourse nel tentativo di risolvere il problema. Il che significava che non avevo accesso al database da nessun’altra parte se non dal backup.

Certamente questo è un caso di nicchia che ho pubblicato qui, l’opzione migliore sarebbe stata notare il problema e risolverlo mentre avevo ancora accesso diretto al database dell’app, ma me lo sono perso e non ho trovato altre opzioni.

1 Mi Piace

Nessun problema. Almeno hai dimostrato che è possibile, hai imparato cose nuove e hai dato ad altri un’opzione aggiuntiva.

Ottimo lavoro! :clap:

3 Mi Piace

Grazie, anche se il file originale era di 128 MB e quello nuovo è di 29 MB, quindi penso che la ricompressione sul server possa aver troncato il file a causa della sua lunghezza.

Questo processo sembra che dovrebbe funzionare, ma il file che ho ottenuto non poteva essere utilizzato per ripristinare il mio discourse.

1 Mi Piace

Il percorso che hai seguito è stato più rischioso ma sicuramente fattibile? Forse qualcuno può intervenire con qualche consiglio su questo problema.
Presumibilmente puoi ripeterlo di nuovo dal backup, quindi…

1 Mi Piace

Questo problema è stato risolto? Sembra una guida, ma il tuo sito sembra ancora bloccato.

Forse stai facendo qualcosa che non capisco, ma di solito puoi semplicemente eseguire ./launcher start app per avviare il vecchio container, c’è stato un motivo per cui non hai potuto farlo?

Quindi puoi usare strumenti Rails o SQL per correggere il tuo database sul vecchio container, e poi provare di nuovo a eseguire il bootstrap/ricostruzione.

O forse hai migrato il database oltre ciò che il tuo vecchio container poteva gestire.

Ho eseguito interventi simili su un backup prima che il sito che veniva ripristinato avesse un anno o più. Penso che il dump del database fosse abbastanza piccolo da poterlo modificare in vim.

1 Mi Piace

Grazie per aver risposto.

Si è rifiutato di avviarsi poiché eravamo qualche aggiornamento indietro, quindi ho aggiornato all’ultima versione di Discourse creandone una nuova e caricando il nostro vecchio backup, ma ha rifiutato quel backup a causa delle chiavi duplicate.

O forse hai migrato il database oltre ciò che il tuo vecchio container poteva gestire.

Sì, probabilmente è così. È un po’ confuso esattamente cosa ho fatto ora, ma ho aggiornato alcune cose in modo indipendente in base ai consigli di risoluzione dei problemi qui. Una di queste è stata ottenere la versione più recente di PostgreSQL.

Sono stato in grado di modificarlo in vim.

Sono stato in grado di modificarlo in Nano, e tutto sembrava a posto, ma il file rizippato era troppo piccolo, quindi qualcosa è andato storto da qualche parte… forse non sono stato in grado di modificarlo in Nano. Sembrava aver funzionato al momento.

Speravo che qualcuno potesse vedere un errore e correggermi, in modo che diventasse una guida su come fare.

Cosa guarderei dopo:

  • Rifare l’intera decompressione. Comprimila senza modifiche. Verifica che la dimensione dello zip sia la stessa di prima. Se non lo è, forse non stai comprimendo con le stesse opzioni?

  • Decomprimi di nuovo, controlla la dimensione del file che stai modificando. Modificalo, salvalo, conferma che la dimensione non è cambiata in modo significativo.

1 Mi Piace

Un piccolo aggiornamento. Qualcun altro nel mio team ci stava lavorando la settimana scorsa ma non è arrivata una soluzione, quindi ho provato di nuovo, questa volta modificando il DB sul mio sistema locale.

Cosa ho fatto:

  1. scaricato un vecchio backup che voglio ripristinare
  2. decompresso i file con 7zip
  3. aperto dump.sql con visual studio code
  4. trovato i tag duplicati direttamente nel DB.
  5. trovato quello che sembrava l’elenco dei tag cercando con ’ ’ attorno al tag. Nel mio caso ‘socialmedia’. I tag sembrano essere il 2° e il 3° dal basso delle istanze trovate.

  1. modificato uno per leggere

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Ricompresso il file dump.sql in 7zip
  • Aggiungi all’archivio
  • Formato archivio .gzip
  1. Ricompresso il file di backup principale
  • Aggiungi all’archivio
  • Formato archivio .tar (gzip non è ancora disponibile)
  1. Ora dovresti vedere un file di backup .tar zippato e corretto

  2. Comprimere il file .tar in 7zip per creare un file .tar.gz, per corrispondere al formato utilizzato da Discourse

  • Aggiungi all’archivio
  • Formato archivio .gzip
  1. Carica nei backup e ripristina tramite la sezione admin

A questo punto ho riscontrato un messaggio di errore:

Estrazione del file di dump…
[2023-08-08 15:09:15] EXCEPTION: Nessun file o directory di questo tipo @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Qualcuno ha qualche idea su cosa mi sia sfuggito nel processo sopra?
L’unica cosa a cui riesco a pensare è che il percorso che sta cercando utilizzi la data odierna e non la data del backup (sto scrivendo questo il 08-08-2023).

Questo è un seguito del mio post precedente qui. Sto postando di nuovo in modo che sia più facile da trovare per chiunque altro lo faccia in futuro, se funziona.

Cosa ho fatto per modificare il DB sul mio laptop:

  1. scaricato il vecchio backup che voglio ripristinare dalla sezione admin
  2. decompresso i file con 7zip
  3. aperto dump.sql con visual studio code
  4. trovato i tag duplicati direttamente nel DB.
  5. trovato quello che sembrava essere l’elenco dei tag cercando usando ’ ’ attorno al tag. Nel mio caso ‘socialmedia’. I tag sembrano essere il 2° e il 3° dal basso delle istanze trovate.

  1. modificato uno per leggere

132 ‘socialmedia2’:1A socialmedia2 en_GB 3

  1. Ricompresso il file dump.sql in 7zip
  • Aggiungi all’archivio
  • Formato archivio .gzip
  1. Ricompresso il file di backup principale
  • Aggiungi all’archivio
  • Formato archivio .tar (gzip non è ancora disponibile)
  1. Ora dovresti vedere un file di backup .tar zippato e corretto

  2. Comprimere il file .tar in 7zip per creare un file .tar.gz, per corrispondere al formato utilizzato da Discourse

  • Aggiungi all’archivio
  • Formato archivio .gzip
  1. Carica nei backup e ripristina tramite la sezione admin

A questo punto ho riscontrato un messaggio di errore:

Estrazione del file di dump…
[2023-08-08 15:09:15] ECCEZIONE: Nessun file o directory di questo tipo @ rb_check_realpath_internal - /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

Qualcuno ha qualche idea su cosa mi sia sfuggito nel processo sopra?
L’unica cosa a cui riesco a pensare è che il percorso che sta cercando utilizzi la data odierna e non la data del backup (sto scrivendo questo il 08-08-2023).

1 Mi Piace

Penso che forse il nome esatto di un file di backup sia importante: nome del forum, data e timestamp, identificatore di versione. Quindi, se disimballi, modifichi e reimballi, suggerirei di ricostruire con lo stesso nome dell’originale. Ma tieni al sicuro l’originale, ovviamente.

1 Mi Piace

Ho combinato i post dal nuovo argomento in questo, poiché sembra che mantenere questo problema raggruppato in un unico posto lo renderà molto più facile da seguire per i futuri viaggiatori. :+1:

1 Mi Piace

Grazie @Ed_S, ho mantenuto il nome originale perché avevo letto altrove che era importante. La mia domanda qui sopra riguarda il motivo per cui lo strumento di ripristino del backup stava cercando e non trovava: /var/www/discourse/tmp/restores/default/2023-08-08-150913/dump.sql.gz

che è la data in cui stavo eseguendo il ripristino.

1 Mi Piace

Ah, scusa. Sembra strano. Potrebbe essere che la directory temporanea si chiami come la data odierna, ma non è un buon segno che il file di dump sql non venga trovato.

Se elenchi il contenuto del file tar, vedi quel nome file al suo interno? Nel mio caso

root@ubuntu-2gb-nbg1-1:/var/discourse/shared/standalone/backups/default# tar vtfz forumname-2023-08-03-HHMMSS-v2023mmddhhmmss.tar.gz dump.sql.gz | head
-rw-r--r-- discourse/www-data 16336925 2023-08-03 05:31 dump.sql.gz
1 Mi Piace

Grazie Ed, quel file non esisteva. Mi scuso per il ritardo, sono stato fuori rete per un po’.

Non c’è un file con il nome corretto lì, quindi ho appena provato a crearne uno vuoto manualmente:

sudo mkdir -p /var/www/discourse/tmp/restores/default/2023-08-22-121010/

ma ogni volta che premo ripristina cerca un file leggermente diverso (le ultime 6 cifre). Presumo che stia cercando una cartella generata da un timestamp, quindi ogni volta che premo il pulsante di ripristino la cartella che cerca è cambiata.

Sospetto che qualcosa non vada nel tuo passaggio 10 dove crei il file tar. Riesci a vederlo? Puoi usare file per descriverlo? Puoi elencare il contenuto con tar tvfz?

1 Mi Piace