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

Installazione
21 
andy@ubuntu-s-1vcpu-1gb-ams3-01:/var/discourse/shared/standalone/backups/default$ file public-happiness-2023-07-25-033857-v20220628031850.tar.gz
public-happiness-2023-07-25-033857-v20220628031850.tar.gz: gzip compressed data, was "public-happiness-2023-07-25-033857-v20220628031850.tar", last modified: Tue Aug  8 14:53:40 2023, max speed, from FAT filesystem (MS-DOS, OS/2, NT)

Il contenuto completo del file sembra a posto, anche se è difficile dirlo dato che si tratta di molte informazioni: Hastebin

22

Penso che abbia a che fare con i percorsi dei file. Dai un’occhiata a

Hmm. Potrebbe non essere quello il problema. Per lo più non mi fido di 7zip per creare un file tar compatibile, ma potrebbe essere irrazionale.

  -h, --dereference
              Segui i symlink; archivia e scarica i file a cui puntano.

La risposta potrebbe essere nel file sopra. In realtà, probabilmente si trova in un altro file nella stessa directory.

1 Mi Piace
23

Grazie: contenuti corretti, ma con nomi errati, credo. Da qui il problema.
Hai

-rwxrwxrwx 0/0        26927534 2023-08-08 14:37 public-happiness-2023-07-25-033857-v20220628031850/dump.sql.gz

ma l’originale e qualsiasi backup non modificato avrebbero

-rwxrwxrwx 0/0        26927534 2023-08-08 14:37 dump.sql.gz

Modifica: quindi devi gestire 7zip in modo leggermente diverso nella creazione di quel file tar.gz.

1 Mi Piace
24

Grazie per tutto il tuo aiuto. Ho decompresso i file, modificato nuovamente il tag duplicato e poi l’ho ricompresso con molta attenzione, prestando particolare attenzione al nome del file, e ci sono progressi!

Ora, durante il ripristino, vedo questo messaggio di errore, che sembra essere molto più comune:

[2023-08-25 15:25:21] CREATE INDEX
[2023-08-25 15:25:21] ERROR:  could not create unique index "index_tags_on_lower_name"
[2023-08-25 15:25:21] DETAIL:  Key (lower(name::text))=(socialmedia) is duplicated.
[2023-08-25 15:25:21] EXCEPTION: psql failed: DETAIL:  Key (lower(name::text))=(socialmedia) is duplicated.

Suppongo che ciò significhi che ho modificato con successo il tag, ma ci sono ancora alcune occorrenze del tag nei post nel mio database. Il numero del tag_id indica che dovrebbe esserci un tag chiamato socialmedia, ma invece sta trovando un tag chiamato socialmedia2, il che sta causando un conflitto.

questo post e quest’altro discutono di correzioni, ma poiché ho accesso al mio backup solo modificando direttamente il codice sulla mia macchina locale, non sono in grado di utilizzare gli strumenti mysql per aiutare a ripulirlo.

Fortunatamente nel mio database ho solo 38 istanze di ‘socialmedia’ (a differenza delle oltre 50.000 occorrenze di socialmedia). Supponendo che io abbia corretto correttamente la riga 395421 come ho mostrato nello screenshot, allora non riesco a capire quali delle rimanenti siano collegate al tag ‘socialmedia’ e quali al tag che ho modificato in ‘socialmedia2’.

Ecco un esempio di un post abbastanza breve che utilizza il tag socialmedia

9488	'/groups/communitybuilders':86 '/groups/socialmedia':84 '/groups/webdev':89 '1st':117 '2022':131 '6':125 'activ':61 'banner':113 'btw':143 'close':169 'comment':21 'communiti':47 'communitybuild':87 'concept':4A 'especi':28 'event':119 'excit':164 'feedback':8B 'final':166 'get':38,133 'github':94 'grow':6A,142 'hack':127 'hard':156 'help':96 'homepag':151 'host':124 'improv':11B 'join':71,106 'launch':41,118,126 'like':128 'link':110 'live':140,175 'lot':27 'love':1A,67 'marvelxi':152 'mean':25 'media':51 'member':62 'mention':93 'move':45 'much':15 'new':150 'one':72,107 'onto':53 'plan':121 'platform':7B,43,139 'pleas':5A 'project':137 'promot':97 're':33,36,56,161 'readi':39,172 'rhorho358':23 'right':63 'see':100,167 'site':176 'slight':76,177,179 'small':58 'smile':77,178,180 'social':50 'socialmedia':85 'stage':31 'suggest':10B 'sure':79 'take':17 'team':59,75,103 'thank':12 'think':147 'time':19 'use':108 'webdev':90 'websit':3A 'whether':80 'work':155 'would':66,82	Grazie mille per aver dedicato del tempo a commentare qui @R , significa molto, specialmente nel st... ha lavorato sodo e siamo tutti molto entusiasti di vederlo finalmente pronto sul sito live :slight_smile: :slight_smile:	en_GB	4	f

Tuttavia, potrei essere sulla strada sbagliata, poiché all’inizio sembrano esserci più tag di quanti un utente possa utilizzare in un post. È anche possibile che ‘socialmedia’ non sia un tag utilizzato nel post sopra, anche se dovrebbe esserlo.

25

Ripristinerei il database manualmente e proverei ad aggiungere gli indici e a correggere i problemi del database piuttosto che un file di testo, ma anche questo è difficile.

26

  1. Non credo che questa sia la conclusione immediata che puoi/dovresti trarre. Il problema dovrebbe essere semplice:

    Il motivo per cui quell’indice non verrà creato è che hai almeno due voci nella tabella tags che si risolvono nella stessa cosa quando prendi la versione minuscola del loro nome. Questo è ciò che ti dice il messaggio di errore.

    Quindi penso che tu debba ancora trovare le voci correlate in quella singola tabella che si scontrano quando si esegue quella trasformazione.

  1. Inoltre, i post non vengono taggati, i topic sì.

Prima di eliminare i duplicati, annota i loro ID perché dovrai eliminare anche le righe correlate dalla tabella topic_tags (qualcosa che avresti potuto risolvere rapidamente se avessi eseguito tutta questa manutenzione online semplicemente riavviando il container invece di distruggere l’istanza!!).

3 Mi Piace
27

Il nostro sito è tornato! Grazie a tutti per il vostro aiuto.

Sembra che avessi risolto giorni fa, ma sono stato negligente nel leggere il messaggio di errore. C’erano due tag duplicati, ‘socialmedia’ e ‘social-media’. Dopo aver corretto il primo, non ho notato che il messaggio di errore era cambiato, data la somiglianza tra i due tag duplicati.

Ecco i passaggi per correggere questi due errori:

1. Trovare la tabella dei tag e il tag duplicato

  • Scarica il backup sul tuo sistema operativo. Questa guida è per Windows, ma il processo sarà più o meno lo stesso su Linux.

  • Estrai tutte le cartelle zippate, che dovrebbero lasciarti un file dump.sql e una cartella uploads.

  • Apri il file dump.sql con un editor di testo, io ho usato Visual Studio Code.

  • Cerca “COPY public.tags” per individuare la tabella dei tag. Dovrebbe trovarsi verso il fondo e apparire così:

image
image895×368 22.7 KB

  • Sfogliala manualmente o copia incolla la tua tabella dei tag in un documento separato dove puoi usare la funzione di ricerca per trovare il tuo tag duplicato.

  • Salva il tuo file dump.sql corretto come dump.sql.

2. L’ordine e i nomi dei file e delle cartelle devono essere perfetti nella ri-compressione.

  • Dopo l’estrazione dovresti avere un file dump.sql e una cartella uploads.

  • Fai clic destro su dump.sql. seleziona 7zip e ‘aggiungi all’archivio’.

  • Seleziona gzip come formato di archivio, mantenendo lo stesso nome del file.

  • Seleziona il nuovo file dump.sql.gz e il file uploads, quindi fai clic destro > 7zip > aggiungi all’archivio > formato archivio: tar. Assicurati che il nome del file sia esattamente lo stesso del backup originale, dovrebbe apparire qualcosa di simile a: ‘public-happiness-2023-07-25-033857-v20220628031850’.

  • Seleziona il tuo nuovo file .tar > 7zip > aggiungi all’archivio > formato archivio: gzip. Assicurati che il nome del file sia esattamente lo stesso del backup originale, dovrebbe apparire qualcosa di simile a: ‘public-happiness-2023-07-25-033857-v20220628031850’.

  • Il tuo risultato finale dovrebbe essere un file .tar.gz con lo stesso nome del tuo backup originale.

  • Carica nell’area admin e ripristina il tuo backup.

3 Mi Piace
28

C’è un altro posto in cui il tag è/potrebbe essere ripetuto ed è la tabella dei dati di ricerca:

COPY public.tag_search_data (tag_id, search_data, raw_data, locale, version) FROM stdin;

Non sono sicuro se anche questo debba essere corretto o meno.

29

Sono così felice che tu l’abbia finalmente sistemato!

2 Mi Piace