Das Upgrade-Skript prüft den freien Speicherplatz und fährt nur fort, wenn dies sicher ist.
Es gibt zwei Schritte im Prozess, bei denen der Festplattenspeicher kritisch werden kann. Wenn du die Prüfung des freien Speicherplatzes umgehen würdest, könntest du hier in Schwierigkeiten geraten:
- Beim Ausführen von pg_dump, um die Daten aus der alten Datenbank zu extrahieren (an dieser Stelle wird das 2-fache des Datenbank-Speichers benötigt).
- Beim Ausführen von pg_restore, um die Daten wieder in die neue Datenbank einzufügen (an dieser Stelle wird das 3-fache des Datenbank-Speichers benötigt).
Um aus diesem Zustand zu recoveren, müsstest du /shared/postgres_dump und /shared/postgres_data_new entfernen.
Beachte, dass wir am Ende des Upgrades die temporären pg_dump-Dateien entfernen, aber deine Datenbankdaten vor dem Upgrade unter /shared/postgres_data_old behalten, nur für den Fall. Sobald du zufrieden bist, dass alles funktioniert, wirst du wahrscheinlich dieses Verzeichnis entfernen wollen, um Festplattenspeicher wiederzugewinnen.
Ich habe getestet, ein Discourse-Backup auf einer PG15-Site zu machen und es auf einer PG18-Site wiederherzustellen. Es hat bei mir funktioniert, aber sei dir bewusst, dass dies keine offiziell unterstützte Methode ist. Teste gründlich auf etwas Nicht-Produktivem zuerst und stelle sicher, dass du einen Rollback-Pfad hast!
Ich würde empfehlen, den Prozess zu studieren, der vom Upgrade-Skript verwendet wird. Wenn du spezielle Speicheranforderungen hast, solltest du in der Lage sein, es an deine Bedürfnisse anzupassen. Wiederum, teste zuerst:
Dies ist nun in discourse_docker, ja. Wenn du main pullst oder ./launcher rebuild app ausführst, wirst du es erhalten.
Das Abschalten von discourse_docker vom main-Branch wird helfen, versehentliche Upgrades zu verhindern, wenn du es aufschieben möchtest.