Datenbank in einem Backup modifizieren, um ein doppeltes Schlüssel-Tag zu entfernen, damit es bei der Wiederherstellung nicht fehlschlägt

Installation
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)

Der vollständige Dateiinhalt sieht in Ordnung aus, obwohl es schwierig ist, das zu sagen, da es viele Informationen sind: Hastebin

22

Ich glaube, es hat etwas mit den Dateipfaden zu tun. Schauen Sie sich das an unter

Hmm. Das ist vielleicht nicht das Problem. Ich vertraue 7zip meistens nicht, um eine kompatible tar-Datei zu erstellen, aber das mag irrational sein.

  -h, --dereference
              Follow symlinks; archive and dump the files they point to.

Die Antwort könnte in der obigen Datei liegen. Eigentlich ist sie wahrscheinlich in einer anderen Datei im selben Verzeichnis.

1 „Gefällt mir“
23

Danke – die richtigen Inhalte, aber unter den falschen Namen, denke ich. Daher das Problem.
Sie haben

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

aber das Original und jedes unveränderte Backup hätte

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

Bearbeiten: Sie müssen also 7zip etwas anders steuern, um diese tar.gz-Datei zu erstellen.

1 „Gefällt mir“
24

Vielen Dank für all Ihre Hilfe. Ich habe die Dateien entpackt, den doppelten Tag erneut bearbeitet und dann sehr sorgfältig wieder gepackt, wobei ich besonders auf den Dateinamen geachtet habe, und es gibt Fortschritte!

Jetzt sehe ich beim Wiederherstellen diese Fehlermeldung, die anscheinend viel häufiger vorkommt:

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

Ich vermute, das bedeutet, dass ich den Tag erfolgreich geändert habe, aber es gibt immer noch einige Vorkommen des Tags in Beiträgen in meiner Datenbank. Die Tag-ID-Nummer besagt, dass es einen Tag namens socialmedia geben sollte, aber stattdessen findet es einen Tag namens socialmedia2, was einen Konflikt verursacht.

Dieser Beitrag und dieser diskutieren Lösungen, aber da ich nur über mein Backup durch direkte Bearbeitung des Codes auf meinem lokalen Rechner Zugriff habe, kann ich die MySQL-Tools nicht zur Bereinigung verwenden.

Glücklicherweise habe ich in meiner Datenbank nur 38 Instanzen von 'socialmedia' (im Gegensatz zu über 50.000 socialmedia-Vorkommen). Angenommen, ich habe die Zeile 395421 wie oben abgebildet korrekt geändert, dann sehe ich nicht, wie ich erkennen kann, welche verbleibenden Instanzen mit dem Tag ‘socialmedia’ und welche mit dem Tag, den ich zu ‘socialmedia2’ geändert habe, verknüpft sind.

Hier ist ein Beispiel für einen ziemlich kurzen Beitrag, der den Tag socialmedia verwendet

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	Danke, dass Sie sich die Zeit genommen haben, hier zu kommentieren @R , es bedeutet viel, besonders in der st... hat hart daran gearbeitet und wir sind alle sehr gespannt, es bald auf der Live-Seite fertig zu sehen :slight_smile: :slight_smile:	en_GB	4	f

Ich bin hier vielleicht auf dem falschen Weg, denn das sehen aus wie mehr Tags am Anfang, als ein Benutzer wahrscheinlich in einem Beitrag verwenden würde. Es ist auch möglich, dass ‘socialmedia’ kein Tag ist, das im obigen Beitrag verwendet wird, obwohl es das sein sollte.

25

Ich würde die Datenbank von Hand wiederherstellen und versuchen, die Indizes hinzuzufügen und die Probleme mit der Datenbank zu beheben, anstatt mit einer Textdatei, aber das ist auch schwierig.

26
  1. Ich glaube nicht, dass das die unmittelbare Schlussfolgerung ist, die Sie ziehen können/sollten. Das Problem sollte einfach sein:

Der Grund, warum dieser Index nicht erstellt werden kann, ist, dass Sie mindestens zwei Einträge in der tags-Tabelle haben, die dasselbe ergeben, wenn Sie den Kleinbuchstaben ihres Namens nehmen. Das sagt Ihnen die Fehlermeldung.

Ich denke also, Sie müssen immer noch die zugehörigen Einträge in dieser einzelnen Tabelle finden, die bei dieser Umwandlung kollidieren.

  1. Außerdem werden Beiträge nicht getaggt, sondern Themen.

Bevor Sie die Duplikate löschen, notieren Sie sich deren IDs, da Sie auch die zugehörigen Zeilen aus der topic_tags-Tabelle löschen müssen (etwas, das Sie schnell hätten erledigen können, wenn Sie all diese Wartungsarbeiten online durchgeführt hätten, indem Sie einfach den Container neu gestartet hätten, anstatt die Instanz zu zerstören!!).

3 „Gefällt mir“
27

Unser Standort ist wieder da! Vielen Dank an alle für Ihre Hilfe.

Es scheint, dass ich es vor Tagen gelöst hatte, aber unachtsam beim Lesen der Fehlermeldung war. Es gab zwei doppelte Tags: ‘socialmedia’ und ‘social-media’. Nachdem ich den ersten korrigiert hatte, bemerkte ich nicht, dass sich die Fehlermeldung geändert hatte, da beide doppelten Tags sehr ähnlich waren.

Hier sind die Schritte zur Behebung dieser beiden Fehler:

1. Finden der Tag-Tabelle und des doppelten Tags

  • Laden Sie das Backup auf Ihr Betriebssystem herunter. Diese Anleitung ist für Windows, aber der Vorgang wird auf Linux ungefähr gleich sein.

  • Extrahieren Sie alle gezippten Ordner, sodass Sie eine dump.sql-Datei und einen uploads-Ordner erhalten.

  • Öffnen Sie die dump.sql-Datei mit einem Texteditor. Ich habe Visual Studio Code verwendet.

  • Suchen Sie nach “COPY public.tags”, um die Tag-Tabelle zu finden. Sie sollte sich ziemlich weit unten befinden und so aussehen:

image
image895×368 22.7 KB

  • Durchsuchen Sie sie entweder manuell oder kopieren Sie Ihre Tag-Tabelle in ein separates Dokument, in dem Sie die Suchfunktion verwenden können, um Ihren doppelten Tag zu finden.

  • Speichern Sie Ihre korrigierte dump.sql-Datei als dump.sql.

2. Die Reihenfolge und die Namen von Dateien und Ordnern müssen beim erneuten Zippen perfekt sein.

  • Nach der Extraktion sollten Sie eine dump.sql-Datei und einen uploads-Ordner haben.

  • Klicken Sie mit der rechten Maustaste auf dump.sql. Wählen Sie 7zip und “Zu Archiv hinzufügen”.

  • Wählen Sie gzip als Archivformat und behalten Sie den Dateinamen bei.

  • Wählen Sie die neue dump.sql.gz-Datei und die uploads-Datei aus, klicken Sie dann mit der rechten Maustaste > 7zip > Zu Archiv hinzufügen > Archivformat: tar. Stellen Sie sicher, dass der Dateiname genau derselbe ist wie beim ursprünglichen Backup. Er sollte ungefähr so aussehen: ‘public-happiness-2023-07-25-033857-v20220628031850’.

  • Wählen Sie Ihre neue .tar-Datei aus > 7zip > Zu Archiv hinzufügen > Archivformat: gzip. Stellen Sie sicher, dass der Dateiname genau derselbe ist wie beim ursprünglichen Backup. Er sollte ungefähr so aussehen: ‘public-happiness-2023-07-25-033857-v20220628031850’.

  • Ihr Endergebnis sollte eine .tar.gz-Datei mit demselben Namen wie Ihr ursprüngliches Backup sein.

  • Laden Sie sie in den Admin-Bereich hoch und stellen Sie Ihr Backup wieder her.

3 „Gefällt mir“
28

Es gibt noch eine weitere Stelle, an der das Tag wiederholt wird/wiederholt werden könnte, und das ist die Suchdatentabelle:

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

Ich bin mir nicht sicher, ob das auch korrigiert werden muss oder nicht.

29

Schön, dass Sie es endlich repariert haben!

2 „Gefällt mir“