Modification de la base de données dans une sauvegarde pour supprimer une balise de clé dupliquée afin qu'elle ne échoue pas lors de la restauration

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)

Le contenu complet du fichier semble correct, bien qu’il soit difficile de le dire car il y a beaucoup d’informations : Hastebin

Je pense que cela a à voir avec les chemins de fichiers. Jetez un œil à

Hmm. Ce n’est peut-être pas le problème. Je ne fais surtout pas confiance à 7zip pour créer un fichier tar compatible, mais c’est peut-être irrationnel.

  -h, --dereference
              Suivre les liens symboliques ; archiver et sauvegarder les fichiers auxquels ils pointent.

La réponse pourrait se trouver dans le fichier ci-dessus. En fait, elle se trouve probablement dans un autre fichier du même répertoire.

1 « J'aime »

Merci - le bon contenu, mais sous les mauvais noms, je pense. D’où le problème.
Vous avez

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

mais l’original et toute sauvegarde non modifiée auraient

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

Modification : vous devez donc piloter 7zip un peu différemment lors de la création de ce fichier tar.gz.

1 « J'aime »

Merci pour toute votre aide. J’ai décompressé les fichiers, modifié à nouveau la balise dupliquée, puis l’ai soigneusement recompressée en prêtant une attention particulière au nom du fichier, et il y a du progrès !

Maintenant, lors de la restauration, je vois ce message d’erreur, qui semble beaucoup plus courant :

[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.

Je suppose que cela signifie que j’ai réussi à modifier la balise, mais qu’il reste encore des occurrences de la balise dans les publications de ma base de données. Le numéro tag_id indique qu’il devrait y avoir une balise appelée socialmedia, mais au lieu de cela, il trouve une balise appelée socialmedia2, ce qui provoque un conflit.

ce post et celui-ci discutent de correctifs, mais comme je n’ai accès à ma sauvegarde qu’en modifiant directement le code sur ma machine locale, je ne peux pas utiliser les outils mysql pour aider à le nettoyer.

Heureusement, dans ma base de données, je n’ai que 38 instances de ‘socialmedia’ (par opposition à plus de 50 000 occurrences de socialmedia). En supposant que j’ai eu raison de modifier celle de la ligne 395421 comme je l’ai montré dans la capture d’écran, alors je ne vois pas comment dire lesquelles des occurrences restantes sont liées à la balise ‘socialmedia’, et lesquelles à la balise que j’ai modifiée en ‘socialmedia2’.

Voici un exemple d’un post assez court utilisant la balise 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	Merci beaucoup d'avoir pris le temps de commenter ici @R , cela signifie beaucoup, surtout dans le st... a travaillé dur dessus et nous sommes tous très impatients de le voir bientôt prêt sur le site en direct :slight_smile: :slight_smile:	en_GB	4	f

Je pourrais cependant être sur la mauvaise piste car cela ressemble à plus de balises au début qu’un utilisateur n’en utiliserait probablement dans un post. Il est également possible que ‘socialmedia’ ne soit pas une balise utilisée dans le post ci-dessus, bien qu’elle aurait dû l’être.

Je restaurerais la base de données manuellement et j’essaierais d’ajouter les index et de corriger les problèmes de la base de données plutôt qu’un fichier texte, mais c’est aussi difficile.

  1. Je ne pense pas que ce soit la conclusion immédiate que vous pouvez/devriez tirer. Le problème devrait être simple :

    La raison pour laquelle cet index ne peut pas être créé est que vous avez au moins deux entrées dans la table tags qui se résolvent en la même chose lorsque vous prenez la version en minuscules de leur nom. C’est ce que le message d’erreur vous dit.

    Je pense donc que vous devez toujours trouver les entrées associées dans cette seule table qui entrent en conflit lors de cette transformation.

  1. De plus, les publications ne sont pas étiquetées, les sujets le sont.

    Avant de supprimer le(s) doublon(s), notez leurs identifiants car vous devrez également supprimer les lignes associées de la table topic_tags (quelque chose que vous auriez pu régler rapidement si vous aviez effectué toute cette maintenance en ligne en redémarrant simplement le conteneur au lieu de détruire l’instance !!).

3 « J'aime »

Notre site est de retour ! Merci à tous pour votre aide.

Il semble que j’aie résolu le problème il y a quelques jours, mais j’ai été négligent en lisant le message d’erreur. Il y avait deux balises dupliquées, ‘socialmedia’ et ‘social-media’. Après avoir corrigé la première, je n’ai pas remarqué que le message d’erreur avait changé, étant donné à quel point ces deux balises dupliquées se ressemblaient.

Voici les étapes pour corriger ces deux erreurs :

1. Trouver la table des balises et la balise dupliquée

  • Téléchargez la sauvegarde sur votre système d’exploitation. Ce guide est pour Windows, mais le processus sera à peu près le même sous Linux.

  • Extrayez tous les dossiers zippés, ce qui devrait vous laisser un fichier dump.sql et un dossier uploads.

  • Ouvrez le fichier dump.sql avec un éditeur de texte, j’ai utilisé Visual Studio Code.

  • Recherchez “COPY public.tags” pour localiser la table des balises. Elle devrait se trouver près du bas et ressembler à ceci :

  • Parcourez-la manuellement, ou copiez-collez votre table des balises dans un document séparé où vous pourrez utiliser la fonction de recherche pour trouver votre balise dupliquée.

  • Enregistrez votre fichier dump.sql corrigé sous le nom de dump.sql.

2. L’ordre et les noms des fichiers et dossiers doivent être parfaits lors du re-zippage.

  • Après extraction, vous devriez avoir un fichier dump.sql et un dossier uploads.

  • Faites un clic droit sur dump.sql. sélectionnez 7zip et ‘ajouter à l’archive’.

  • Sélectionnez gzip comme format d’archive, en gardant le même nom de fichier.

  • Sélectionnez le nouveau fichier dump.sql.gz et le fichier uploads, puis faites un clic droit > 7zip > ajouter à l’archive > format d’archive : tar. Assurez-vous que le nom du fichier est exactement le même que celui de la sauvegarde d’origine, il devrait ressembler à ceci : ‘public-happiness-2023-07-25-033857-v20220628031850’.

  • Sélectionnez votre nouveau fichier .tar > 7zip > ajouter à l’archive > format d’archive : gzip. Assurez-vous que le nom du fichier est exactement le même que celui de la sauvegarde d’origine, il devrait ressembler à ceci : ‘public-happiness-2023-07-25-033857-v20220628031850’.

  • Votre résultat final devrait être un fichier .tar.gz portant le même nom que votre sauvegarde d’origine.

  • Téléchargez dans la zone d’administration et restaurez votre sauvegarde.

3 « J'aime »

Il y a un autre endroit où la balise est/pourrait être répétée, et c’est la table de données de recherche :

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

Je ne suis pas sûr si cela doit également être corrigé ou non.

Tellement content que vous ayez enfin réussi à le réparer !

2 « J'aime »