Einfach Discourse die Aufgabe überlassen. Dies erfordert das Dreifache des aktuellen Speicherplatzes. Wenn Ihre Datenbank also 100 GB groß ist, benötigen Sie für das Upgrade weitere 200 GB freien Speicherplatz. Das ist offensichtlich ein riesiges Problem für Nutzer mit großen Installationen.
Das “manuelle Update”-Verfahren befolgen. Dies erfordert das Doppelte des Speicherplatzes, also bei einer 100 GB-Datenbank weitere 100 GB freien Speicher. Auch das ist für manche ein großes Problem.
In diesem Beitrag schlug @Falco vor, die Option --link zu verwenden, um das Upgrade vor Ort mittels Hardlinks durchzuführen. Der von ihnen empfohlene Docker-Container unterstützt dieses Argument, aber die Discourse-Entwickler empfehlen es in dem Beitrag nicht.
Meine Frage ist also: Sollte Option 3 lauten:
Den folgenden Befehl ausführen, der nur einen sehr kleinen zusätzlichen Speicherplatz benötigt. Wenn Ihre Datenbank also 100 GB groß ist, wären es vielleicht nur zusätzliche 10 GB? Falls ja, wird dieses Verfahren von den Discourse-Entwicklern empfohlen, und hat es jemand bereits erfolgreich durchgeführt?
Neuer Befehl für das Upgrade vor Ort:
docker run --rm \
-v DIR:/var/discourse/shared/standalone/postgres_data:/var/lib/postgresql \
tianon/postgres-upgrade:12-to-13 \
--link
Zum Vergleich der alte Befehl für das Upgrade in ein neues Verzeichnis (erfordert doppelten Speicherplatz):
P.S.: Ich hätte einfach auf den PG13-Upgrade-Thread geantwortet, aber Beiträge werden dort nach 7 Tagen gelöscht. Warum ist das so konfiguriert? Ich weiß, dass es damals viel Diskussion gab, die als Referenz sehr nützlich gewesen wäre.
Falls ja, haben sie es hier nicht erwähnt. Die meisten Anweisungen hier versuchen, so fehlertolerant wie möglich zu sein und so wenig Systemverwaltungswissen wie möglich vorauszusetzen. Die meisten Leute hier bevorzugen eine Methode, die so sicher und so gut getestet wie möglich ist, anstatt einer Methode, die darauf ausgelegt ist, ein paar wenige Dollar zu sparen.
Wenn es bei dir funktioniert, kannst du das PostgreSQL 13-Update entsprechend aktualisieren. Aber bevor du das tust: Fühlst du dich wohl damit, jemandem, der nicht weiß, was Bash ist, zu empfehlen, es so zu machen? Bist du sicher, dass dies ihre Datenbank nicht zerstört und ihre Website für immer ruiniert?
Die Idee dahinter ist, dass, wenn andere gute Informationen präsentiert werden, diese zum ursprünglichen Beitrag (OP) hinzugefügt werden, anstatt die Leute zu bitten, ein Jahr an Beiträgen zu lesen, die wahrscheinlich nicht hilfreich oder falsch sind.
Nein, ich bin mir nicht sicher. Ich habe nicht viel Erfahrung mit PostgreSQL und hatte gehofft, dass einer der Discourse-Entwickler bestätigen kann, dass es funktioniert.
Selbst wenn es funktioniert, würde ich es nicht als Standard-Upgrade-Verfahren empfehlen, da die alte Methode eine separate Kopie der Datenbank für einen Rollback behält. Wenn es funktioniert, wäre es jedoch eine hervorragende Option für Umgebungen mit begrenztem Speicherplatz.
Eine weitere einfache Möglichkeit besteht darin, einen neuen Server hochzufahren, die Daten zu migrieren und den alten abzuschalten. Falls du den alten unbedingt nutzen musst, führe das Upgrade auf einem temporären Server durch, installiere das Original neu (was wahrscheinlich ein Betriebssystem-Upgrade erfordert) und verschiebe es anschließend zurück.
Das ist sicher, einfach und gut dokumentiert. Hunderte von Leuten haben das bereits gemacht.
Ja, aber das würde ein oder zwei Tage dauern. In dieser Zeit könnten wir entweder a) den Nutzern mitteilen, dass ihre Beiträge in diesem Zeitraum verloren gehen, oder b) das Forum auf schreibgeschützt stellen. Keine der beiden Optionen ist eine ideale Lösung.
Ich denke nicht, dass der Server viel länger außer Betrieb sein wird als während des Neuaufbaus. Und wenn du auf den neuen Server wechselst und dort bleibst, kannst du den alten Server im Nur-Lese-Modus lassen, während du den Wechsel vornimmst. Wenn Ausfallzeiten dein Anliegen sind, dann ist der Wechsel auf einen neuen Server viel, viel besser.
Wir haben ein recht großes Forum, aber ich habe noch nie versucht, ein Backup wiederherzustellen, daher weiß ich nicht, wie lange das dauern würde. Falls wir es tun würden, blieben wir tatsächlich beim neuen Host. Ich würde das gerne vermeiden, wenn möglich, wegen des zusätzlichen Aufwands und der Unannehmlichkeiten.
Eine andere Möglichkeit, das Problem des Upgrades bei begrenztem Speicherplatz zu lösen, besteht darin, ein Backup zu erstellen, das Postgres-Verzeichnis mit rm -r zu löschen, neu zu erstellen und dann das Backup wiederherzustellen. Ich habe dies letzte Woche auf einer Website gemacht.
Nein, es wurde nie ein Upgrade durchgeführt. Das Löschen der DB und das Wiederherstellen des Backups klingt ziemlich riskant. Wir brauchen im Grunde ein In-Place-Upgrade.
Wir verwenden Ubuntu 18.04, das 2023 nicht mehr unterstützt wird. Ich gehe davon aus, dass wir zu diesem Zeitpunkt keine andere Wahl haben werden, als zu einem neuen Host zu migrieren, und planen, dann in den sauren Apfel zu beißen, einen neuen Host mit 22.04 LTS einzurichten und aus dem Backup wiederherzustellen.
Hmm. Könnte eine Geldverschwendung sein. Ich denke, mit dem Backup-Modell ist eine der Kopien komprimiert, was einen Unterschied machen könnte? Und die Seite, auf der ich es gemacht habe, hatte Backups auf S3. Und es war eine Testseite, also waren die Einsätze bei einem Problem gering.
Außer dass Backups viel öfter und in viel mehr Situationen verwendet werden als das In-Place-Upgrade. Ich halte es für viel sicherer.
Vielleicht, aber ich habe nicht viel Erfahrung mit Postgres und fühle mich damit nicht wohl. Die gesamte Website aus einem Backup auf einer völlig anderen VM wiederherzustellen, damit fühle ich mich wohl, allerdings würde das bedeuten, Beiträge für wie viele Stunden auch immer zu verlieren, die die Wiederherstellung dauert, also bin ich auch davon nicht gerade begeistert. Aber da 18.04 nicht mehr unterstützt wird, werde ich nächstes Jahr nicht viel Wahl haben.
Es sei denn, Ihre Datenbank ist mehrere zehn Gigabyte groß, dann dauert es keine Stunden. Und Sie werden das Forum in den schreibgeschützten Modus versetzen, bevor Sie ein Backup und eine Wiederherstellung durchführen, sodass Sie keine Beiträge verlieren. Es ist nicht so schwer, mit praktisch keiner Ausfallzeit zu tun, nur mit Lesezeit.
root@forum-app:/shared/postgres_data# du -sh
97G .
Ich würde es nicht schreibgeschützt machen, ich würde ein Banner anbringen, das den Leuten sagt, dass ihre heutigen Beiträge flüchtig sind. Besser, sie darüber reden zu lassen, auch wenn diese Beiträge verloren gehen würden, meiner Meinung nach.
Bis dahin haben Sie auch Zugriff auf den integrierten Discourse-Chat, eine Funktion, die mit 2.9 ausgeliefert wird (möglicherweise standardmäßig deaktiviert, aber in der Betaversion und zur Nutzung unterstützt).