Backups schlagen bei Postgres 16 Datenbank (und allen PG>13) fehl

Backups funktionieren nicht mehr für eine PostgreSQL 16-Datenbank aufgrund von diesem Commit, der postgresql-client-${PG_MAJOR} anstelle von postgresql-client installiert.

Löst dies ein Problem? Hatte der vom Betriebssystem bereitgestellte psql-Client nicht mit allen PostgreSQL-Versionen einwandfrei funktioniert?

Ich war überrascht, dass dieser Client PG16 auf einer Digital Ocean-Datenbank verwendete, aber ich dachte, ich wüsste, dass einige CDCK-Hosting jetzt PG15 verwenden.

Gibt es eine bessere Möglichkeit, ein funktionierendes Backup zu erhalten als etwas wie dieses:

run:
  - exec:
      cd: /var/www/discourse
      cmd:
        - apt-get update && apt-get remove -y postgresql-client-13 && apt-get install -y postgresql-client-16

Vielleicht kann ich PG_MAJOR in einer ENV-Variable setzen?

2 „Gefällt mir“

Yep, das scheint der Fall zu sein.

Aus dem PR:

Ich habe diesen Fehler entdeckt, als ein Discourse-Backup mit pg_dump Version 17.2 erstellt wurde, das nicht auf PostgreSQL-Cluster < 17.2 wiederhergestellt werden kann.

Scheint, als wärst du hier zwischen Fels und hartem Ort (PostgreSQL: Documentation: 18: pg_dump)

Da pg_dump verwendet wird, um Daten auf neuere Versionen von PostgreSQL zu übertragen, kann die Ausgabe von pg_dump auf PostgreSQL-Serverversionen geladen werden, die neuer als die Version von pg_dump sind. pg_dump kann auch von PostgreSQL-Servern sichern, die älter als seine eigene Version sind. (Derzeit werden Server bis Version 9.2 unterstützt.) pg_dump kann jedoch nicht von PostgreSQL-Servern sichern, die neuer als seine eigene Hauptversion sind; es wird sich weigern, es überhaupt zu versuchen, anstatt zu riskieren, eine ungültige Sicherung zu erstellen. Außerdem ist nicht garantiert, dass die Ausgabe von pg_dump in einen Server einer älteren Hauptversion geladen werden kann – nicht einmal, wenn die Sicherung von einem Server dieser Version erstellt wurde. Das Laden einer Sicherungsdatei in einen älteren Server erfordert möglicherweise eine manuelle Bearbeitung der Sicherungsdatei, um Syntax zu entfernen, die vom älteren Server nicht verstanden wird.

Ups. Und ich dachte, ich hätte den PR gelesen. Da ich englischer Muttersprachler mit einem Doktortitel bin, könnte man meinen, ich könnte es besser. :person_shrugging:

Nein. Das kann ich nicht, da dies das Basis-Image erstellt.

Es sieht also so aus, als ob meine Korrektur so gut wie möglich ist, obwohl ich, wenn ich schlauer wäre, die apt-Sachen entfernen würde, die ich mit apt-get update hereinziehe.

Ich stelle mir vor, dass einige andere dieses Problem haben werden, da es oft schwierig ist, verschiedene Menschen und Systeme davon zu überzeugen, dass man PG13 und nicht etwas Aktuelleres möchte. Und es scheint, dass es schon ziemlich lange her ist, dass jemand, der es weiß, sagte, dass Discourse mit PG15 funktionierte.

Danke, Richard!

1 „Gefällt mir“

Schlagen die Backups still fehl?

(Ich sehe, dass meine normale Installation Version 13 verwendet, daher gehe ich davon aus, dass diese Situation etwas speziell, wenn auch vielleicht nicht sehr selten ist.)

Sie tun es nicht. Es ist also ziemlich offensichtlich und sollte nur Leuten passieren, die genug wissen, um ihre eigene Postgres zu verwalten.

1 „Gefällt mir“

Hallo zusammen, ich bin heute auf dieses Problem gestoßen. Das Symptom war, dass wir seit etwa 6 Tagen Warnungen erhielten, dass Backups fehlschlagen, und die wichtigsten Log-Zeilen schienen zu lauten:

[2025-06-14 03:30:20] pg_dump: error: aborting because of server version mismatch
[2025-06-14 03:30:20] pg_dump: detail: server version: 16.9; pg_dump version: 15.12 (Debian 15.12-1.pgdg120+1)

Ich betreibe Discourse unter Ubuntu auf einem Digital Ocean Droplet und verwende die empfohlene Installationsanleitung. Aber ich verwende die Managed Postgres-Datenbank von Digital Ocean anstelle eines Postgres-Containers. Wenn ich mir meine Datenbank ansehe, läuft sie mit pg 16. Ich glaube nicht, dass sie sie kürzlich aktualisiert haben (und ich würde sowieso keine automatische Hauptversionsaktualisierung erwarten), aber ich habe ihren Support per E-Mail kontaktiert, um dies zu überprüfen.

Jedenfalls führte meine Recherche zu dieser Seite. Ich war mir nicht sicher, wo ich das YAML platzieren sollte, das @pfaffman gepostet hat, also habe ich die Befehle manuell ausgeführt und dachte, ich würde sie für alle anderen teilen, die auf dieses Problem stoßen:

  • cd /var/discourse
  • launcher enter app
  • apt list --installed | grep postgres # um zu bestätigen, dass die aktuell installierte Version 15 ist
  • apt-get update
  • apt-get remove postgresql-client-15
  • apt-get install postgresql-client-16

Ich habe dann ein manuelles Backup auf der Admin-Backup-Seite ausgelöst.

Dies scheint das Problem vorübergehend behoben zu haben, aber wie @pfaffman angemerkt hat, erwarte ich, dass bei der nächsten Discourse-Aktualisierung zu postgresql-client-15 zurückgekehrt wird und Backups wieder fehlschlagen, was die oben genannte manuelle Intervention erfordert.

Gibt es eine Lösung für dieses Problem, abgesehen davon, dass ich diese Schritte jedes Mal wiederholen muss, wenn ich Discourse aktualisiere?

Ich glaube, irgendwo hier stelle ich die Sachen zur Verfügung, um diese Befehle in Ihre app.yml einzufügen.

Sie können sich vielleicht die Postgres-Vorlagen als Beispiele ansehen.

Danke, aber ich bin mir nicht sicher, ob ich das richtig verstehe. Ich hatte den Eindruck, dass das YAML, das Sie im ursprünglichen Beitrag oben erwähnt haben, lediglich eine Möglichkeit war, die Befehle von den wenigen, die ich oben gepostet habe, auf einen einzigen zu reduzieren, aber dass Sie ihn trotzdem jedes Mal manuell ausführen mussten, wenn Sie Discourse aktualisieren. Habe ich das falsch interpretiert?