"AUSNAHME: psql fehlgeschlagen: DETAIL: Schlüssel (post_id)=(36946) ist doppelt vorhanden."

Installation
1

Ich versuche, meinen Server zu einem neuen Hoster zu migrieren, daher habe ich eine Sicherungsdatei heruntergeladen und auf den neuen Hoster hochgeladen. Ich habe eine frische Kopie von Discourse installiert und die Anweisungen von der Befehlszeile befolgt:

Leider schlägt discourse restore databasename mit folgender Fehlermeldung fehl:

ALTER TABLE
ALTER TABLE
ALTER TABLE
ERROR:  could not create unique index "posts_search_pkey"
DETAIL:  Key (post_id)=(36946) is duplicated.
EXCEPTION: psql failed: DETAIL:  Key (post_id)=(36946) is duplicated.
/var/www/discourse/lib/backup_restore/database_restorer.rb:92:in `restore_dump'
/var/www/discourse/lib/backup_restore/database_restorer.rb:26:in `restore'
/var/www/discourse/lib/backup_restore/restorer.rb:51:in `run'
script/discourse:149:in `restore'

Es scheint, als ob etwas mit der Datenbankdatei nicht stimmt? Kann mir jemand Hinweise geben, wie ich diesen Fehler beheben kann? Ich habe noch Zugriff auf den ursprünglichen Server, der anscheinend einwandfrei funktioniert.

Gibt es einen SQL-Befehl oder etwas Ähnliches, das ich ausführen kann, um die Datenbank zu analysieren (und zu reparieren?), bevor ich ein Backup herunterlade?

2

Es scheint, als hätten Sie einen beschädigten Index. Welche PostgreSQL-Version ist das?

Es gibt ein paar Themen dazu. Sie können versuchen, diese Tabelle auf der laufenden Instanz neu zu indizieren und dann die doppelten IDs zu löschen oder zu korrigieren.

3

Ja, ich glaube, es ist beschädigt. Ich würde mich freuen, wenn mir jemand sagen könnte, wie ich es reparieren kann :slight_smile:

Postgres ist 13.6. Ich versuche, es auf eine neue Instanz auf einem anderen Server zu verschieben.

Ich habe rake search:reindex innerhalb des Docker-Containers ausprobiert, und es schlägt mit Folgendem fehl:

........rake aborted!
PG::UniqueViolation: ERROR:  duplicate key value violates unique constraint "posts_search_pkey"
DETAIL:  Key (post_id)=(86919) already exists.

Ist es möglich, den fehlerhaften Datensatz einfach zu löschen und neu zu indizieren oder so etwas?

Jede Hilfe wird geschätzt!

4

Ich empfehle, die Zeile einfach zu löschen, das ist der einfachste Weg.

2 „Gefällt mir“
5

Kann mir jemand psql-Befehle geben, mit denen ich die fehlerhaften Zeilen identifizieren und entfernen kann?

Danke, das ist sehr nett!

6

Ich glaube, es ist so etwas wie

./launcher enter app
su - postges
psql discourse
select id from post_search_data where post_id>86918 and post_id<86921;
--- wenn du die ID hast ----
delete from post_search_data where id=ID_FROM_LAST_QUERY

Es könnte mehr geben.

Vielleicht kann jemand anderes mehr helfen, aber das ist alles, was ich tun kann, ohne auf deinem Server angemeldet zu sein. Wenn du mehr Hilfe benötigst, kannst du im Marketplace posten oder mich direkt kontaktieren.

Oder vielleicht ist es sicher, es einfach zu löschen und neu generieren zu lassen, aber da bin ich mir nicht ganz sicher.

7

Danke für die Hilfe, Leute.

Ich konnte Folgendes tun:

discourse=# reindex index concurrently "posts_search_pkey";
ERROR:  could not create unique index "posts_search_pkey_ccnew2"
DETAIL:  Key (post_id)=(116038) is duplicated.
discourse=# delete from post_search_data
where post_id = 116038;
DELETE 2
discourse=# delete from post_search_data
where post_id = 116038;
DELETE 0
discourse=# reindex index concurrently "posts_search_pkey";
ERROR:  could not create unique index "posts_search_pkey_ccnew3"
DETAIL:  Key (post_id)=(9336) is duplicated.
discourse=# delete from post_search_data
where post_id = 9336;
DELETE 1
.
.
.
.
discourse=# reindex index concurrently "posts_search_pkey";
REINDEX

Als alles in Ordnung schien, habe ich ein vollständiges Backup erstellt und es ohne Probleme auf einem neuen Server wiederhergestellt.

Ich schätze die Zeit aller Beteiligten. Ich liebe Discourse!

Lektion gelernt: Überprüfen Sie Backups gelegentlich, um sicherzustellen, dass sie gut sind :slight_smile: Ich führe tägliche Backups durch und behalte auch monatliche “Schnappschüsse”. Das älteste Backup, das ich hatte und das keine beschädigte Datenbank aufwies, war 4 Monate alt :frowning:

5 „Gefällt mir“
8

Großartig! Ich bin froh, dass Sie es geschafft haben!

@sam Was beunruhigend ist, ist, dass ich dachte, die Erklärung sei, dass dies ein Problem mit PG<13 sei, aber Sie verwenden PG13.

9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.