PostgreSQL 18-Update für Self-Hoster

[Lilly (Lillian)]

@Ed_S

Ich würde wahrscheinlich den Wildcard ergänzen, falls noch Reste von Upgrades vorhanden sind.

gute Idee, danke Ed! Ich habe meinen Beitrag aktualisiert.

[LotusJeff]

Durch diese Änderung habe ich eine allgemeine Reduzierung des Speicherverbrauchs um etwa 4 % festgestellt. Gut gemacht.

[AstonJ]

@Lilly

Ja, ich habe vor ein paar Wochen Upgrades für Dual-Container auf einem Server durchgeführt (auch auf einem russischen Server). Es gab keinerlei Probleme, aber stelle sicher, dass du vorher genug Festplattenspeicher hast.

Danke Lilly, ich habe das Upgrade gerade durchgeführt und alles scheint in Ordnung zu sein

[ecki (Bernd)]

Dass umgeschriebene Tabellen und Indizes deutlich kompakter werden, ist nichts Ungewöhnliches.

[ecki (Bernd)]

Äh, das liegt im normalen Betrieb von Postgres (je nachdem, ob man vor oder nach VACUUM, Tabellenrebuild usw. hinschaut)

[peternlewis]

Seither habe ich nichts vermisst, also soweit ich das beurteilen kann, ist alles in Ordnung.

[terminus]

Ich betreibe Discourse in einem eigenständigen Docker-Container unter /var/discourse.

Ich habe versucht, die eingebettete PostgreSQL-Datenbank von Version 15 auf 18 zu aktualisieren. Das Upgrade schien abgeschlossen zu sein, und das aktive Datenverzeichnis meldet nun:

/shared/postgres_data/PG_VERSION
18

Der neu aufgebaute Discourse-Container enthält jedoch weiterhin nur die PostgreSQL-15-Binaries:

/usr/lib/postgresql/15/bin/postgres
postgres (PostgreSQL) 15.18

Der PostgreSQL-Dienst ist so konfiguriert, dass er ausgeführt wird:

/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main

während das eigentliche Discourse-Datenverzeichnis eingehängt ist unter:

/shared/postgres_data

PostgreSQL schlägt folglich mit folgendem Fehler fehl:

FATAL: database files are incompatible with server

DETAIL: The data directory was initialized by PostgreSQL version 18,
which is not compatible with this version 15.18
(Debian 15.18-1.pgdg12+1).

Ich verstehe, dass aktuelle Discourse-Docker-Images die PostgreSQL-18-Binaries enthalten sollen. Ich habe app.yml geändert, um die PostgreSQL-18-Vorlage zu verwenden, und die App neu aufgebaut, aber der resultierende Container hat weiterhin die PostgreSQL-15-Binaries und das Skript des Dienstes verweist immer noch auf /etc/postgresql/15/main.

Der relevante Teil meiner aktuellen Dienstkonfiguration lautet:

HOME=/var/lib/postgresql USER=postgres exec thpoff \
chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert \
/usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main

Meine Fragen lauten:

1. Was ist der korrekte Weg, den Discourse-Container so neu aufzubauen oder zu aktualisieren, dass er tatsächlich die PostgreSQL-18-Binaries enthält?

2. Gibt es eine bestimmte Vorlage oder einen bestimmten Image-Tag, der in app.yml verwendet werden sollte?

3. Sobald PostgreSQL 18 verfügbar ist, welches unterstützte Verfahren gibt es, es gegen das bestehende /shared/postgres_data-Verzeichnis zu starten?

Ich habe das PostgreSQL-18-Datenverzeichnis weder gelöscht noch neu initialisiert. Ich würde den aktualisierten Cluster wiederherstellen, anstatt die alten PostgreSQL-15-Daten wiederherzustellen.

[merefield (Robert)]

@terminus

Ich habe app.yml geändert, um die PostgreSQL-18-Vorlage zu verwenden.

basierend auf den Anweisungen im OP scheint das ein unnötiger Schritt gewesen zu sein, es sei denn, ich übersehe etwas?

Einfach nur ein Standard-Install neu aufzubauen, hätte das neueste Image ziehen und die Migration auslösen sollen.

Es sei denn, man wählt bewusst das neueste Image aus, die neuen Binaries waren sicher garantiert? Sehr seltsam …

Bist du sicher, dass du kein Image festgelegt (gepinnt) hast?

[terminus]

@merefield

basierend auf den Anweisungen im Eröffnungspost scheint das ein unnötiger Schritt gewesen zu sein, es sei denn, ich übersehe etwas?

Nur das Standard-Installat neu aufzubauen, hätte das neueste Image ziehen und die Migration auslösen sollen.

Es sei denn, man wählt bewusst nicht das neueste Image aus – dann waren die neuen Binaries doch garantiert? Sehr seltsam …

Bist du dir sicher, dass du kein Image festgepinnt hast?

Nicht absichtlich? Ich nutze das reguläre Git-Repository und den Branch, und in meiner app.yml steht nichts, was darauf hindeuten würde, dass ich etwas festgepinnt habe. Ich habe nur das postgres-18-Template geändert, um zu sehen, ob das hilft; ja, das war ein unnötiger Schritt, der nicht geholfen hat, also kann ich das wieder zurückändern.

Gibt es Vorschläge, wie ich die neuen Binaries bekomme? Sie sind wirklich nicht da, egal wie oft ich neu baue:

root@hostname-app:/usr/lib/postgresql# ls -la

total 12

drwxr-xr-x 1 root root 4096 May 21 00:47 .

drwxr-xr-x 1 root root 4096 May 21 00:48 ..

drwxr-xr-x 1 root root 4096 May 21 00:47 15

root@hostname-app:/usr/lib/postgresql#

[merefield (Robert)]

@terminus

Gibt es Vorschläge, wie man die neuen Binaries bekommt?

Um dir Zeit und Aufwand zu sparen, würde ich vorschlagen, mit deinem letzten Backup einen neuen Server einzurichten – das erspart dir viel Arbeit.

Ihre Discourse-Instanz auf einen anderen Server verschieben

Dies ist eine Anleitung zum Verschieben Ihrer Discourse-Instanz von einem Server auf einen anderen, einschließlich aller Einstellungen und Daten. Diese Anleitung gilt für selbst gehostete Discourse-Instanzen, die Docker verwenden. Erforderliche Benutzerebene: Systemadministrator Dieses Verfahren beinhaltet Änderungen an Domänen und DNS. Stellen Sie sicher, dass Sie Zugriff auf den Quell- und den Zielserver haben. Diese Anleitung führt Sie durch den…

[terminus]

Okay, stimmt schon! Manchmal lohnt es sich nicht, sich mit dem Reparieren aufzuhalten. Danke.

[agemo]

Wenn du das Admin-Panel nicht erreichst, weil dein Discourse-Forum verrückt spielt, wie holst du dir die Datenbank über root@, um sie auf einer neuen Instanz hochzuladen? (Vielleicht gibt es dafür einen anderen Leitfaden)

Oder gibt es einen Befehl, der per Kommandozeile dasselbe bewirkt wie über das Admin-Panel?

[agemo]

Okay, und um auf den Punkt zu kommen: Ich muss die App neu aufbauen, um einen Zertifikatsfehler zu beheben, der offenbar gerade erst aufgetreten ist (keine Änderungen hatten den scheinbaren Fehler vorher verursacht) – der Fehler „Port 443 nicht erreichbar“ taucht auf (der Assistent meldet: „DNS-Verifizierung fehlgeschlagen“) – ich weiß nicht, ob Cloudflare oder DigitalOcean etwas geändert haben, aber auch hier wurde auf meiner Seite nichts verändert. Ich kann die App aber nicht neu aufbauen, vermutlich wegen dieser beiden Fehler, einschließlich des unten stehenden. Letztes Mal war es ein „nicht genügend Speicherplatz“-Fehler. Hast du eine Idee, wie ich den unten stehenden Fehler umgehen kann?

Zusätzlich: Ich habe genau denselben Fehler auch schon vor und nach der Vergrößerung der primären Festplatte bekommen (um den Speicherbedarf von PostgreSQL 15 auf 18 zu berücksichtigen).

FAILED

--------------------

Pups::ExecError: if [ -f /root/install_postgres ]; then

  /root/install_postgres && rm -f /root/install_postgres

elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then

  socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1

fi

failed with return #<Process::Status: pid 17 exit 1>

Location of failure: /usr/local/lib/ruby/gems/3.4.0/gems/pups-1.4.0/lib/pups/exec_command.rb:138:in 'Pups::ExecCommand#spawn'

exec failed with the params {"tag" => "db", "cmd" => "if [ -f /root/install_postgres ]; then\n  /root/install_postgres && rm -f /root/install_postgres\nelif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then\n  socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1\nfi\n"}

[agemo]

Ah, ok, ich habe gefunden, was ich brauche, und zwar von @Lilly, die das schon lange in diesem Thema gepostet hat:

cd /var/discourse
./launcher enter web_only
discourse backup
exit

Daraus schließe ich, dass ich damit ein nutzbares DB-Backup erstellen kann, das ich auf einer neuen Discourse-Instanz hochladen und damit alle Probleme umgehen kann.

Liefert dieser Befehl ein vollständiges Backup, also Posts + Uploads/Bilder?

[pfaffman (Jay Pfaffman)]

Ich würde ein Backup nur der Datenbank empfehlen und rsync verwenden, um alles andere zu übertragen. Eine Discourse-Website mit rsync auf einen anderen VPS übertragen. Du kannst auch die SSL-Zertifikate mit rsync übertragen, damit du die neue Website hochfahren kannst, bevor du die DNS-Einträge änderst.

So mache ich es: Changing Digital Ocean droplets with doctl (resize, floating ip, rename, etc) - Howto - Literate Computing Dashboard

EDIT: Entschuldigung. Ich kann nicht sagen, ob du dein Problem gelöst hast oder nicht. Wenn ich es richtig verstehe, ist das Einfachste, auf die Standard-Vorlage ohne Versionsnummer zurückzuschalten und erneut aufzubauen.

[ecki (Bernd)]

Hast du den Daten- (in deinem Fall wahrscheinlich den App-)Container wie gefordert zweimal neu aufgebaut?

(Übrigens steht in der Update-Meldung, man solle die App neu aufbauen, aber ich vermute, es war „der Datenbank-Container, der möglicherweise app oder data heißt“ gemeint – oder ist tatsächlich beides gemeint?)

Und noch ein kurzes Feedback: Vor einiger Zeit habe ich versucht, von 13 auf 15 zu wechseln, aber es ist mehrfach fehlgeschlagen und ich blieb beim .13-Template. Als nun .18. angeboten wurde, habe ich es erneut versucht und es hat problemlos funktioniert (ich musste vorher nur die _new- und _older-Verzeichnisse aufräumen). Damit kann ich wieder mit dem standardmäßigen, versionlosen Daten-Template arbeiten. Also gut gemacht, das Update so robust zu gestalten.

[ecki (Bernd)]

Ich habe gerade im Fehlerprotokoll bemerkt, dass vor dem PG-Update einige SQL-bezogene Fehler in den Logs auftauchten:

Job exception: PG::UndefinedFunction: ERROR: function array_remove(bigint[], integer) does not exist LINE 1: ...ATE "access_control_lists" SET allowed_user_ids = array_remo...

Das ist seltsam, denn diese Funktion stammt aus PG9, und ich habe zuvor Version 15 verwendet. Könnte es sich um ein Berechtigungs- oder Suchpfad-Problem handeln? Es scheint, als würde der Fehler nach dem DB-Update nicht mehr auftreten, aber vielleicht liegt es an der Batch-Zeitsteuerung… Ich sehe die Funktion an ziemlich vielen Stellen verwendet, sogar in Migrations-Skripten.

Vielleicht bedeutet das, dass einige Funktionen in älteren PostgreSQL-Versionen fehlschlagen, obwohl ihre Vorlagen noch aufgelistet sind. Vielleicht habe ich es übersehen, aber ich dachte, die älteren Versionen wären kompatibel.