PostgreSQL 18-Update für Self-Hoster

[pfaffman (Jay Pfaffman)]

@chrisr

Wir haben gerade Änderungen eingeführt, um unser Docker-Image auf PostgreSQL 18 zu aktualisieren.

Das Literate Computing-Dashboard hat erfolgreich zwei Standalone-Sites und eine Zwei-Container-Site ohne Zwischenfälle aktualisiert. Meistens war nur die Änderung der Ziel-Postgres-Version in einer Variablen erforderlich, sodass der Prozess, wie angekündigt, mit den letzten mehreren Updates identisch war.

@chrisr

Ich habe getestet, ein Discourse-Backup auf einer PG15-Site zu erstellen und auf einer PG18-Site wiederherzustellen. Es hat bei mir funktioniert, aber beachte, dass dies keine offiziell unterstützte Methode ist.

Es ist tatsächlich ziemlich gut unterstützt und viel sicherer als ein Upgrade der Datenbank-Hauptversion. Falls etwas schiefgeht, musst du den Wechsel zum neuen Server einfach nicht durchführen. Wenn du bald ein OS-Upgrade benötigst und/oder minimale Ausfallzeiten möchtest, ist dies ein guter Ansatz. Du hast Lesezugriff, während du den neuen Server aufbaust, und schaltest dann darauf um. Der einfache Weg bedeutet nur Ausfallzeit für den finalen Neuaufbau, oder gar keine Ausfallzeit, wenn du die Zertifikate vom alten Server kopierst.

Falls bei einem Datenbank-Upgrade alles schiefgeht, ist der Aufbau eines neuen Servers und die Wiederherstellung des Backups die einfache Lösung.

Stelle sicher, dass du ein Backup erstellst, bevor du beginnst. Ich mache ein Backup nur der Datenbank, da du deine Uploads nicht verlierst.

[Firefishy (Grant)]

HINWEIS: Der genaue Grund ist mir nicht klar, aber das PostgreSQL 18-Upgrade deaktiviert die nativen Daten-Checksummen. Daten-Checksummen sind eine Standardfunktion von PostgreSQL, und es wirkt sehr ungewöhnlich, diese zu deaktivieren.

[Firefishy (Grant)]

PR zur Verhinderung der Deaktivierung von Daten-Checksums (standardmäßig aktiviert): Do not disable PostgreSQL 18 data checksums - Pull Request #1105 - discourse/discourse_docker - GitHub

[merefield (Robert)]

Und es ist besser, als 20 GB frei haben zu müssen für die eine Stunde, in der du sie in einem Jahr brauchst lol

Vielleicht sollte dies der empfohlene Ansatz sein, um Bäume und Wasser zu sparen.

[elmuerte]

Nur zur Bestätigung: Ich verwende nicht das von Discourse bereitgestellte PostgreSQL, und Discourse erfordert auch noch kein PG18, oder? Also bin ich (noch) nicht verpflichtet, auf PG18 zu aktualisieren.

[pfaffman (Jay Pfaffman)]

@merefield

Und es ist besser, als 20 GB freien Speicherplatz haben zu müssen für die eine Stunde, in der du ihn in einem Jahr brauchst lol

Guter Punkt. Aber der andere Punkt ist, dass LTS-Versionen alle paar Jahre erscheinen, also ist es keine schlechte Idee, das gleichzeitig zu machen.

@elmuerte

Nur zur Bestätigung: Ich verwende nicht das von Discourse bereitgestellte PostgreSQL und Discourse selbst erfordert noch nicht PG18, oder? Also bin ich (noch) nicht gezwungen, auf PG18 zu aktualisieren.

Du hast definitiv noch Zeit. Sie haben für . . . äh, eine bestimmte Version ziemlich schnell nach dem Update gedrängt, weil eine Funktion erforderlich war, aber du kannst wahrscheinlich bis zu einem Jahr warten. Ich beobachte das discourse_docker-Repo. Irgendwann werden sie anfangen, über die Entfernung der Unterstützung für PG15 zu sprechen; es ist nicht besonders laut und ist ein einfacher Weg, um mit Updates der internen Dinge Schritt zu halten.

[Falco]

Funktionierte einwandfrei auf meiner Pi 5-Installation, zwei Neubauten und fertig.

[merefield (Robert)]

Haben wir übrigens irgendwelche Benchmarks?

Das könnte andere dazu ermutigen, uns schneller in unseren heldenhaften Fußstapfen zu folgen.

Meine kostenlose KI-Suchmaschine sagt mir:

Für eine typische Rails-App kann der Wechsel von PostgreSQL 15 → 18 zu ~10–25 % schnellerer Abfrageleistung führen, ohne dass Codeänderungen erforderlich sind, und bis zu 40 % bei bestimmten Abfragemustern, wenn man die neuen Indexierungs- und Planerfunktionen nutzt.

Wenn das stimmt, ist das ein ziemlich guter Upgrade!

[satonotdead]

Nur zur Bestätigung, dass alles in unserer selbst gehosteten Instanz einwandfrei verlief. Danke für dieses Update und haltet uns auf dem Laufenden.

[chrisr (Chris Rendle-Short)]

@pfaffman

Es ist eigentlich ziemlich gut unterstützt, es ist viel sicherer als ein Upgrade einer Datenbank auf eine höhere Hauptversion.

Stimmt, aber wir zielen auf einen einfachen, transparenten Upgrade-Mechanismus ab. Beide Ansätze haben ihre Vorzüge.

Ich würde sagen, mach, was dir am besten gefällt, und scheue dich nicht, die Vorlagen in discourse_docker nach deinen Anforderungen anzupassen. Offensichtlich ist der Schlüssel, zuerst zu testen und einen Rollback-Plan zu haben.

@Firefishy

Ich bin mir nicht sicher, warum, aber das PostgreSQL 18-Upgrade deaktiviert die nativen Daten-Checksummen. PostgreSQL-Daten-Checksummen sind eine Standardfunktion, und es scheint sehr ungewöhnlich, sie zu deaktivieren.

Auf unserer gehosteten Plattform beabsichtigen wir, vor dem Aktivieren dieser Funktion weitere Tests und Benchmarks durchzuführen, und daher habe ich sie auch in discourse_docker deaktiviert, um die Konfiguration abzugleichen. Es ist jedoch nicht zwingend erforderlich, sie zu deaktivieren (intern verwenden wir nur den Web-Container-Teil von discourse_docker), und ich wäre nicht dagegen, sie zu aktivieren.

Ein potenzielles Problem ist, dass pg_upgrade nicht funktioniert, wenn die alten und neuen Datenverzeichnisse unterschiedliche Checksummen-Einstellungen haben. Der Prozess müsste so ablaufen: Den PG15-Server herunterfahren, pg_upgrade ausführen, um ihn ohne Checksummen zu PG18 zu konvertieren, pg_checksums ausführen, um die Checksummen zu aktivieren, und dann PG18 starten. Dies ist kein Problem bei einer Dump- und Wiederherstellungsprozedur (wie bei diesem Upgrade), aber etwas, auf das man achten sollte.

Beachte, dass Daten-Checksummen seit Postgres 9.3 verfügbar sind, aber bis jetzt standardmäßig deaktiviert waren. Postgres 19 wird auch die Möglichkeit enthalten, sie online zu aktivieren/deaktivieren.

@elmuerte

Nur zur Bestätigung: Ich verwende nicht das von Discourse bereitgestellte PostgreSQL, und Discourse selbst erfordert PG18 noch nicht, richtig? Also bin ich (noch) nicht verpflichtet, auf PG18 zu upgraden.

Derzeit nicht, nein. Die meisten Discourse-Funktionen verwenden den Rails PostgreSQL-Adapter, um mit der DB zu kommunizieren, aber Backup/Wiederherstellung verwendet pg_dump und psql im Web-Container. Momentan installieren wir sowohl PG15- als auch PG18-Clients, um Backup/Wiederherstellung mit beiden Versionen zu ermöglichen, aber irgendwann in der Zukunft werden wir PG15 entfernen.

@pfaffman

Sie drängten auf . . . äh, ein Release ziemlich schnell nach dem Update, weil eine bestimmte Funktion erforderlich war

Der treibende Faktor war der Wechsel zum neuen integrierten Lokalisierungsanbieter. Wir arbeiten an einem OS-Upgrade auf unserer gehosteten Plattform und möchten die Kopplung mit glibc aufbrechen.

[Eviepayne (vladtheimplier)]

Ich verwalte mein Postgres unabhängig vom Container. Welcher Git-Hash wird empfohlen, um auf pg18 umzusteigen?

[chrisr (Chris Rendle-Short)]

e7f1201 fügte den PG18-Client zur Web-Image für die Backup-Kompatibilität hinzu. Wenn du keine der Postgres-Server-Komponenten von discourse_docker verwendest, ist dies die früheste Revision, die du für PG18 verwenden solltest.

[pfaffman (Jay Pfaffman)]

@chrisr

Der Hauptgrund war der Wechsel zum neuen integrierten Lokalisierungsanbieter.

Ich sprach vor ein oder zwei Upgrades.

@chrisr

Stimmt, aber wir streben einen einfachen, transparenten Upgrade-Mechanismus an. Beide Ansätze haben ihre Vorteile.

Einverstanden. Mein Punkt war nur, dass es nicht weniger unterstützt wird, ein älteres PostgreSQL-Backup auf einer neueren Version wiederherstellen zu können. Der In-Place-Upgrade-Mechanismus funktioniert für die überwiegende Mehrheit der Nutzer hervorragend, aber wenn etwas schiefgeht, ist es schwer zu wissen, was man tun soll (hauptsächlich, weil es so selten vorkommt).