Wir betreiben eine größere Discourse-Installation auf einem VPS-Setup, das im Grunde sehr gut für uns funktioniert. In Bezug auf CPU/Speicher-Leistung haben wir noch Luft nach oben. Der Festplattenspeicher ist jedoch ein kleines Problem - nicht im täglichen Geschäft, sondern wenn es z.B. um die Aktualisierung von Postgres geht (das 13->15-Upgrade steht deswegen noch aus), fehlt uns der Platz und wir können ihn nicht einfach erweitern.
Ich weiß, dass es andere Möglichkeiten für das Postgres-Update gibt, aber betrachten Sie dies eher als eine allgemeine Frage.
Wir laufen auf Hetzner, wo Netzwerkspeicher für den temporären Gebrauch leicht verfügbar ist.
Auf unserem Testserver spiele ich jetzt damit herum, es temporär zum Laufen zu bringen - zuerst, um ein Backup von der Live-Seite wiederherzustellen, später, um das Postgres-Upgrade zu testen. Bisher war ich nicht erfolgreich.
Ich habe bereits versucht, Symlinks zu erstellen, aber festgestellt, dass dies nicht funktioniert, und auch hier irgendwo gelesen, dass dies nicht die empfohlene Methode ist. Ich habe auch versucht, das /shared-Verzeichnis von /var/discourse/shared/standalone nach /mnt/ext-storage/standalone zu verschieben und die Dateien dorthin zu übertragen - leider nicht ohne Probleme. Ich kann den Build nicht einmal abschließen.
Gibt es eine Möglichkeit, die für solche Fälle funktioniert? Ich bin mir bewusst, dass die Laufwerksleistung viel schlechter ist als die des lokalen Laufwerks, aber ich plane nicht, das Forum darauf laufen zu lassen. Ich hätte wirklich nur gerne eine komfortable Möglichkeit, es für bestimmte Szenarien zu nutzen.
Wenn Ihr Ziel darin besteht, das Upgrade so einfach wie möglich zu gestalten, erstellen Sie eine neue VM und migrieren Sie dorthin. Sie überspringen die Notwendigkeit, die Datenbank zu aktualisieren, und erhalten ein neues Betriebssystem auf Ihrer VM, was Sie wahrscheinlich sowieso tun müssen.
Wenn Ihre Backups auf S3 gespeichert sind, ist es sehr einfach, das alte einzufrieren, ein Backup zu erstellen und das Backup auf der neuen Maschine wiederherzustellen.
Wenn Hetzner eine Art permanente IP-Adresse hat, die verschiedenen Servern zugewiesen werden kann, müssen Sie nicht einmal die DNS-Einstellungen ändern.
Sie möchten wissen, dass Sie einen neuen Server erstellen können, damit Sie dies tun können, falls Sie dies aus irgendeinem Grund jemals tun müssen. Dies ist eine perfekte Gelegenheit zum Üben.
Das ist eigentlich keine Option. Es geht sowieso nicht um den Platz für den täglichen Bedarf. Außerdem haben wir derzeit eine 600-GB-Festplatte und nutzen etwa 50 %. Es gibt keine größere Option – zumindest nicht bei Hetzner.
Deshalb habe ich ausdrücklich nach der externen Festplatte gefragt.
Haben Sie interessehalber einen ./launcher cleanup app ausgeführt? Hat das nicht genügend Speicherplatz freigegeben, um das Upgrade vor Ort durchzuführen?
Ich habe nicht vorgeschlagen, auf eine größere Festplatte umzusteigen, sondern nur einen neuen Server genau wie diesen zu beschaffen. Installieren Sie Discourse, stellen Sie Ihre Datenbank wieder her.
Das ist eine sehr gute Frage.
Ja. Jeder Rebuild erstellt einen neuen Container und jeder davon nimmt Platz in Anspruch. Wenn Sie das noch nie getan haben, könnten Sie Dutzende von GB freigeben.
Unser Update-Leitfaden enthält eine Anleitung für Ihren genauen Anwendungsfall.
Wir haben diese Option für Leute hinzugefügt, die sich in der gleichen Situation wie Sie befinden. Stellen Sie einfach sicher, dass Sie ein Backup extern speichern, bevor Sie dies versuchen!
Wenn Sie sich auf einer VM befinden, ist es viel, viel einfacher, einfach zu einer neuen zu wechseln, und es gibt viele Vorteile. Hier sind einige davon:
Null Risiko – wenn etwas schiefgeht, haben Sie immer noch Ihren alten Server
Null Ausfallzeit (nur schreibgeschützt auf dem alten Server)
Sie erhalten das Betriebssystem-Upgrade, das Sie wahrscheinlich sowieso benötigen
Sie können überprüfen, ob Sie wissen, wie Sie einen neuen Server hochfahren, falls eine Katastrophe eintritt
Danke, das ist die andere Option, von der ich weiß, dass sie existiert. Danke trotzdem, dass du darauf hingewiesen hast.
Ich bezweifle das nicht – ich hätte trotzdem gerne die Option erkundet, zusätzlichen Speicherplatz für Wartungsaufgaben hinzuzufügen, falls erforderlich.
Es kann praktisch sein, Ihre Uploads oder z. B. /var/discourse/shared/web_only auf Netzwerkspeicher zu legen. Sie müssen die YML-Datei bearbeiten, um darauf zu verweisen, anstatt einen Symlink zu verwenden (der Symlink funktioniert nicht, da der Container nicht auf den Ort zugreifen kann, auf den Ihr Symlink verweist).
Wenn Sie dann zu einer neuen VM wechseln, können Sie diesen Netzwerkspeicher einfach neu einhängen, anstatt ihn zu kopieren.
Ich empfehle keinen Netzwerkspeicher für die Datenbank, da er langsamer ist.
Ich denke, es lohnt sich, aufzuschlüsseln, wie sich Ihre Nutzung zusammensetzt. Ihre tatsächliche Datenbankgröße ist möglicherweise nicht so groß, wenn der Großteil Ihrer Nutzung aus Uploads besteht und nur der Datenbankteil möglicherweise das 3-fache des Speicherplatzes während eines Upgrades benötigt.
Eine Sache, die Sie überprüfen können, ist die relative Größe eines Backups mit Downloads im Vergleich zu einem Backup ohne Downloads.
Oder verwenden Sie die Befehlszeile. Hier sind einige Ausgaben meines eher kleinen Forums:
Ich hätte anfangs präziser sein sollen, aber ich hatte nicht erwartet, so viel Feedback zu erhalten.
Unsere Uploads und Backups befinden sich auf S3. Die Datenbankgröße auf dem Live-System beträgt jetzt etwa 230 GB. Komprimierte Backups sind, glaube ich, etwa 25 GB groß.
Ich glaube, das sollte es. Ich bin mir nicht sicher, was es auslöst. Ich denke, ein zusätzliches zu machen, schadet nicht und könnte Ihnen etwas Speicherplatz sparen. Es wird empfohlen, es nach dem Upgrade durchzuführen, wenn Sie es vor Ort durchführen. Ich habe gesehen, dass es einige Male erheblichen Speicherplatz bereinigt hat.
Wenn Ihre Datenbank 230 GB groß ist, würde ich sie definitiv auf einem neuen Server wiederherstellen. Die Ausfallzeit beim Lesen und Schreiben von 230 GB wird erheblich sein.