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.
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
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. 
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.
Guter Punkt. Aber der andere Punkt ist, dass LTS-Versionen alle paar Jahre erscheinen, also ist es keine schlechte Idee, das gleichzeitig zu machen.
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.
2 „Gefällt mir“
Funktionierte einwandfrei auf meiner Pi 5-Installation, zwei Neubauten und fertig.
7 „Gefällt mir“
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! 
7 „Gefällt mir“
Nur zur Bestätigung, dass alles in unserer selbst gehosteten Instanz einwandfrei verlief. Danke für dieses Update und haltet uns auf dem Laufenden.
5 „Gefällt mir“
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.
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.
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.
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.
3 „Gefällt mir“
Ich verwalte mein Postgres unabhängig vom Container. Welcher Git-Hash wird empfohlen, um auf pg18 umzusteigen?
1 „Gefällt mir“
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.
1 „Gefällt mir“
Ich sprach vor ein oder zwei Upgrades.
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).
2 „Gefällt mir“
Falls es jemandem hilft, für die Momente, in denen die SSH-Konsole stillsteht und das kalte Angstschweiß-Feeling einsetzt…
Ich habe dies in einem anderen Terminal ausgeführt, um den Fortschritt im Auge zu behalten:
watch -n 10 'df -h /; echo; du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'Dies aktualisiert sich alle 10 Sekunden und bewahrt dich vor dem Wahnsinn
Meine 35-GB-Migration dauerte etwa 10 Minuten.
8 „Gefällt mir“
Das Update ging bei mir mit der Standardinstallation problemlos durch. Davor habe ich natürlich noch ein Backup gemacht und runtergerladen falls etwas schief gehen könnte 
3 „Gefällt mir“
Schön. Ich würde dazu noch ein free -h hinzufügen – Speichermangel ist ein häufiges Problem.
Das einzige Problem bei watch oder tatsächlich top ist, dass sie ständig aktualisiert werden, sodass man etwas verpassen könnte. Wenn du etwas ausläufst und das Update fehlschlägt, hast du ein paar Sekunden später die Aufzeichnung verloren. Daher tendiere ich dazu, etwas mehr wie eine while-Schleife auszuführen – vielleicht so:
while true; do date; echo; free -h; echo; df -h /; echo; sh -c 'du -sh /var/discourse/shared/standalone/postgres_data* 2>/dev/null'; sleep 10; echo; done
4 „Gefällt mir“
Ich kann einen Erfolg vermelden . . . bei der Hälfte meiner Multisite-Konfiguration. Die Standardsite wurde wie erwartet migriert, die sekundäre Site sah jedoch aus wie eine Neuinstallation. Glücklicherweise ist es nicht schwer, ein Backup wiederherzustellen. Ich habe einen weiteren Server, den ich für Kunden nutze, und überlege, einen neuen Droplet zu erstellen und die Sites aus Backups wiederherzustellen, um dieses Update durchzuführen. Das ist wohl eines der Risiken einer nicht-standardmäßigen Installation.
1 „Gefällt mir“
War dein Datencontainer ein Standard-Datencontainer? Ich habe mich gefragt, ob er nur eine einzelne Datenbank oder alle im Cluster verschieben würde. Es klingt so, als hättest du meine Frage beantwortet!
Was ich bisher gemacht habe, ist das manuelle Verschieben jeder Datenbank vom alten zum neuen Cluster, dann das manuelle Bearbeiten von discourse.conf, um auf die neue Datenbank zu verweisen, und schließlich ein Rebuild, um den gesamten Multisite-Container auf den neuen Cluster (auf einer anderen Maschine oder einem anderen Port) zu zeigen.
1 „Gefällt mir“
Ja. Ich kann natürlich nicht ausschließen, dass ich bei meiner Einrichtung etwas falsch gemacht habe. 
Ich hatte vor, meine PostgreSQL-Daten per rsync zu synchronisieren, um dort ein Upgrade durchzuführen, um sicherzustellen, ob der Prozess nur die Discourse-Datenbank oder den gesamten Cluster verschoben hat. Aber es klingt so, als hättest du meine Frage bereits beantwortet, und das wird klar, wenn ich mir den Code ansehe.
2 „Gefällt mir“
Hier habe ich zwei Fragen:
- Wir haben einen zusätzlichen Speicherblock auf dem Testserver eingebunden. Das PostgreSQL-Upgrade schlägt jedoch fehl, da die Platzprüfung nur die Hauptfestplatte überprüft. Gibt es eine Möglichkeit, die Platzprüfung zu umgehen?
- Für unsere Produktionsumgebung verwenden wir Google Cloud SQL. Gibt es etwas, das wir vor dem Upgrade über Google Cloud wissen sollten?