Verschieben Sie eine Discourse-Website mit rsync auf einen anderen VPS

Community-Wiki Systemadministratoren
,
21

Hallo!

Ich versuche, die Schritte von @scottfsmith zu befolgen. Ich schaffe es, rsync zu erledigen. Es ist mir nicht wichtig, die aktuellsten Änderungen über rsync zu erhalten, da ich nur eine neue Linux-Version mit meiner bestehenden Website teste, um zu sehen, ob alle meine Plugins funktionieren. Daher führe ich den zweiten rsync-Lauf nicht durch. Dann führt der Versuch, ./launcher rebuild app auszuführen, zu Fehlern.

2022-12-13 14:43:01.974 UTC [59] LOG:  Datenbanksystem wurde unterbrochen; zuletzt bekannt bis 2022-12-13 10:23:29 UTC
2022-12-13 14:43:02.075 UTC [59] LOG:  ungültiger primärer Checkpoint-Datensatz
2022-12-13 14:43:02.075 UTC [59] PANIC:  konnte keinen gültigen Checkpoint-Datensatz finden
2022-12-13 14:43:03.137 UTC [56] LOG:  Startprozess (PID 59) wurde durch Signal 6 beendet: Aborted
2022-12-13 14:43:03.137 UTC [56] LOG:  Start wird wegen Fehlers des Startprozesses abgebrochen
2022-12-13 14:43:03.231 UTC [56] LOG:  Datenbanksystem ist heruntergefahren
I, [2022-12-13T14:43:06.699692 #1]  INFO -- :
I, [2022-12-13T14:43:06.711862 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
createdb: Fehler: konnte keine Verbindung zur Datenbank template1 herstellen: konnte keine Verbindung zum Server herstellen: Datei oder Verzeichnis nicht gefunden
        Läuft der Server lokal und akzeptiert er
        Verbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2022-12-13T14:43:06.917008 #1]  INFO -- :
I, [2022-12-13T14:43:06.917421 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
psql: Fehler: konnte keine Verbindung zum Server herstellen: Datei oder Verzeichnis nicht gefunden
        Läuft der Server lokal und akzeptiert er
        Verbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2022-12-13T14:43:07.007654 #1]  INFO -- :
I, [2022-12-13T14:43:07.008155 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
psql: Fehler: konnte keine Verbindung zum Server herstellen: Datei oder Verzeichnis nicht gefunden
        Läuft der Server lokal und akzeptiert er
        Verbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2022-12-13T14:43:07.087098 #1]  INFO -- :
I, [2022-12-13T14:43:07.087319 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
psql: Fehler: konnte keine Verbindung zum Server herstellen: Datei oder Verzeichnis nicht gefunden
        Läuft der Server lokal und akzeptiert er
        Verbindungen über den Unix-Domain-Socket "/var/run/postgresql/.s.PGSQL.5432"?
I, [2022-12-13T14:43:07.167221 #1]  INFO -- :
I, [2022-12-13T14:43:07.168041 #1]  INFO -- : Beende asynchrone Prozesse

Ich kann daraus nicht genug erkennen, um eine Lösung zu finden. Einige Suchen deuten darauf hin, dass der Container gestoppt werden muss, aber er ist nicht gestartet. Irgendwelche Ideen?

Danke
David

22

Ich würde einen Staging-Server einrichten, um Ihr spezielles Problem zu lösen.

Nach diesen Fehlern zu urteilen, scheint die Datenbank defekt zu sein. Sie müssen die Datenbank stoppen, um einen gültigen Datensatz zu erhalten, mit dem sie arbeiten kann. Der zweite rsync ist nicht optional.

1 „Gefällt mir“
23

Wow!

Ein vier Jahre alter Thread und eine Antwort innerhalb von 3 Minuten! :slight_smile:

Auf jeden Fall ist es im Grunde ein Staging-Server, den ich anstrebe und diese rsync-Methode verwende. Aber empfehlen Sie, es nicht auf diese Weise mit rsync zu tun, sondern ein Backup zu verwenden? Ich erinnere mich, dass ich nicht alle Anpassungseinstellungen von einem früheren Staging-Server erhalten habe, den ich eingerichtet habe, aber vielleicht irre ich mich.

Danke

1 „Gefällt mir“
24

Das beschreibt dieser Link.

Alles, außer den Plugins (die in Ihrer app.yml stehen), ist im Backup enthalten; die Datenbank und die Uploads sind alles, was es gibt.

1 „Gefällt mir“
25

Aus meinen Tests dieser Methode scheint es auszureichen, ./launcher stop app vor dem anfänglichen rsync auszuführen. Natürlich besteht einer der Gründe für die Verwendung dieser Methode darin, das Forum so lange wie möglich auf dem alten Server am Laufen zu halten. In diesem Fall ist es offensichtlich notwendig, das zweite rsync auszuführen, um die Konsistenz zu wahren. Aber für den relativ gängigen Prozess, ein Forum auf einen anderen Server und/oder Host zu verschieben, bei dem eine kurze Ausfallzeit akzeptabel ist, gefällt mir die Einfachheit und Portabilität dieser Methode wirklich gut.

1 „Gefällt mir“
26

Richtig.

Richtig.

Meine bevorzugte Methode ist, die Let’s Encrypt- und SSL-Sachen per rsync zu übertragen, den alten Server in den schreibgeschützten Modus zu versetzen, ein Backup zu erstellen, auf dem neuen Server wiederherzustellen und dann die DNS zu ändern (oder besser gesagt, eine statische IP, wenn der neue Server bereit ist).

Aber wenn Ihnen eine kleine Ausfallzeit nichts ausmacht, ist Ihre Methode großartig.

2 „Gefällt mir“
27

Ich plane, im Januar nach einigen jüngsten Problemen beim Upgrade von Discourse auf meinem alten Ubuntu auf einen neuen VPS umzuziehen.

Meine Fragen zur Migration von einem alten Digital Ocean Droplet zu einem neuen Digital Ocean Droplet sind:

  • Ich plane, die TTL des DNS A-Eintrags am Tag vor meiner Migration auf etwas Kleines wie 5 Minuten zu senken. Klingt das vernünftig?

  • Der erste Beitrag in diesem Thread wurde zuletzt im Juni 2016 bearbeitet. Ist er noch gültig und korrekt?

  • Kopiert diese rsync-Methode auch die gesamte Datenbank vom alten VPS auf den neuen VPS?
    – Wir verwenden eine Standardinstallation

  • Wird das vorhandene Let’s Encrypt SSL-Zertifikat auch kopiert? Ist das SSL-Zertifikat überhaupt an eine IP-Adresse gebunden oder verknüpft? Wird es sich weiterhin automatisch erneuern? Gibt es hier Fallstricke?

  • An welchem Punkt sollte ich den öffentlichen DNS A-Eintrag ändern, damit er auf den neuen VPS zeigt?
    – Und auch die TTL wieder auf etwas Höheres ändern

28

Das ist alles richtig.

Wenn Sie etwas verwenden, das eine permanente IP-Adresse ermöglicht, die mehreren VMs zugewiesen werden kann, können Sie dies tun, damit Sie sich nicht auf DNS verlassen, um den Wechsel vorzunehmen.

Die einzige Vorsichtsmaßnahme, die ich hinzufügen würde, ist, die alte Website für den endgültigen rsync herunterzufahren und dann im schreibgeschützten Modus neu zu starten, während die neue erstellt wird.

29

Der erste Beitrag zeigt immer noch den falschen Pfad /var/discourse/:

Könnten Sie das bitte bearbeiten/aktualisieren?

30

@Richie, @JammyDodger hat dies jetzt zu einem Wiki gemacht :+1:

2 „Gefällt mir“
31

Ich bin heute zu einem neuen VPS migriert und dachte, ich teile meine Erfahrungen, da es so aussieht, als ob in letzter Zeit einige Leute auf den alten Betriebssystem-Blocker bei ihren Updates stoßen :blush:

Ich bin bei Digital Ocean, also habe ich ein neues Droplet erstellt.

Alter VPS = Ubuntu Server 18.04.6 LTS

Neuer VPS = Ubuntu Server 23.10

Ich habe die üblichen Wartungsarbeiten auf dem neuen VPS durchgeführt - bitte bearbeiten Sie sie nach Belieben:

Apt-get update

Apt-get upgrade

Apt-get install fail2ban

ufw default deny incoming

ufw default allow outgoing

ufw allow ssh

ufw allow http

ufw allow https

ufw enable

Dann habe ich ein neues leeres Verzeichnis für Discourse erstellt:

sudo mkdir -p /var/discourse

Dann habe ich Docker installiert:

wget -qO- https://get.docker.com/ | sh

Dann habe ich die TTL meines DNS von 30 Minuten auf 10 Minuten geändert (das Minimum, das GoDaddy erlaubt).

Auf meinem alten Server habe ich eine lokale Kopie des Discourse-Datenbank-Backups von letzter Nacht heruntergeladen (man kann nie genug lokale Backups haben). Ich habe auch eine Kopie von app.yml auf meinen lokalen PC heruntergeladen.

Wie von einigen Leuten oben vorgeschlagen, habe ich ein “Root-zu-Root”-Rsync durchgeführt. Ich habe die IP-Adresse anstelle des Hostnamens verwendet, um DNS-Verwechslungen zu vermeiden. Ebenfalls wie oben vorgeschlagen, habe ich die Schalter -avz verwendet:

rsync -avz root@old.ip.address.here:/var/discourse /var

Zur Referenz, mein Discourse-Ordner ist 25 GB groß.

Das Rsync vom alten Server zum neuen Server dauerte ca. 25 Minuten. Dies geschah einfach zwischen zwei Digital Ocean Droplets in derselben LON1-Region. Ihre Erfahrungen können abweichen.

Nach dem Rsync und dem Versuch eines Rebuilds stieß ich auf denselben Fehler, auf den @piratdavid wegen PostgreSQL stieß: “database system is shut down”.

Also habe ich die App auf dem alten VPS gestoppt:

./launcher stop app

Und habe noch ein Rsync durchgeführt, diesmal nur für die Änderungen:

rsync -avz --delete root@old.ip.address.here:/var/discourse /var

Dann habe ich die alte Discourse-App wieder gestartet und sehr schnell in den Wartungsmodus versetzt - damit die Leute sie weiterhin erreichen können und die übliche Wartungswarnung sehen.

Das verschafft mir auch etwas Zeit, um am neuen VPS zu arbeiten :blush:

Ich habe meine HOSTS-Datei auf meinem lokalen PC aktualisiert, damit ich auf das Discourse auf dem neuen VPS zugreifen konnte, ohne Browserwarnungen / -probleme.

Auf dem neuen VPS habe ich dann Folgendes ausgeführt:

./discourse-setup

Dies geschah, damit die RAM- und CPU-Einstellungen in der Datei app.yml automatisch aktualisiert werden konnten.

Dann habe ich einen App-Rebuild auf dem neuen VPS durchgeführt:

./launcher rebuild app

Einige Rauchtests durchgeführt, alles gut.

DNS aktualisiert - Auftrag erledigt.

Vielen Dank für das detaillierte Thema, alle :smiley:

3 „Gefällt mir“
32

Danke Leute, erster Beitrag aktualisiert bzgl. /var/discourse-Pfaden.

1 „Gefällt mir“
33

Wenn jemand Probleme hat, das Root-zu-Root-Rsync durchzuführen, weil er vielleicht die Root-Anmeldung auf dem alten Server deaktiviert hat, oder wenn Sie dies einfach als Nicht-Root-Benutzer tun möchten, fand ich diesen Beitrag hilfreich, um herauszufinden, wie man sudo auf dem Remote-Server verwendet: https://askubuntu.com/questions/719439/using-rsync-with-sudo-on-the-destination-machine

Nehmen wir an, Sie haben auf beiden Seiten einen Benutzer, discourse, der über sudo-Berechtigungen verfügt. Auf dem Remote-Computer bearbeiten Sie die Datei /etc/sudoers mit sudo visudo. Sie fügen die Zeile hinzu:

discours ALL=NOPASSWD:/usr/bin/rsync

Dann führen Sie auf dem neuen Computer (als Ihr Nicht-Root-Benutzer) Folgendes aus:

sudo rsync -avz --delete --rsync-path="sudo rsync" discourse@old.ip.address.here:/var/discourse /var

Dies ermöglicht es Ihnen, alles, was hier beschrieben wird, als Nicht-Root-Benutzer auszuführen. Wenn Sie den alten Server behalten, würde ich zurück in die Datei /etc/sudoers gehen und die Zeile löschen, die Sie gerade eingefügt haben.

1 „Gefällt mir“
34

Wenn ich das richtig verstehe, ermöglicht dies, dass der Großteil der Übertragung stattfindet, während Discourse läuft. Die Wiederherstellung aus einem Backup erfordert mindestens Lesezugriff für das Backup und das Verschieben des Backups auf den neuen Server (oder die Übertragung über einen S3-Bucket). Bei großen Websites kann dies zu erheblichen Lesezeiten führen, die die Rsync-Strategie geschickt vermeidet.

Es wäre vielleicht möglich, die Ausfallzeit etwas zu verkürzen, indem man PostgreSQL auf dem alten System nicht herunterfährt und das Problem auf dem neuen System mit pg_resetwal „behebt“. Hinweis: Ich habe dies nicht ausprobiert und es ist fast sicher besser, die Datenbank ordnungsgemäß herunterzufahren.

Ich frage mich, ob es eine Möglichkeit gibt, Discourse im schreibgeschützten Modus zu starten? Ich vermute, der schnellste Weg ist über die Befehlszeile, nachdem der Container läuft.

Auf jeden Fall vielen Dank, dass Sie Ihre Erfahrungen mitgeteilt haben! Es scheint ein nützlicher Prozess zu sein, den man im Hinterkopf behalten kann. :slight_smile:

35

Sehr.

So nützlich, dass ich versucht bin, alles noch einmal zu tun, um eine Staging-Umgebung (auf einem VPS mit geringerer Spezifikation) zu erstellen, nur zum Testen und zur Vorbeugung von Problemen, bevor Änderungen an der Produktion vorgenommen werden.

1 „Gefällt mir“
37

Hallo,

Ich versuche gerade, diesen Prozess auf einer älteren Discourse-Instanz durchzuführen, für deren Wartung ich jetzt verantwortlich bin – Umzug von einem EOL Ubuntu auf etwas Neueres, da jedes Upgrade fehlschlägt, wenn ich es vor Ort versuche – und obwohl rsync erfolgreich war, schlägt PostgreSQL fehl und meldet Probleme mit dem Dateibesitz. Das Ausführen von rsync als Root mit den Optionen zur Beibehaltung des Besitzes hat dies nicht behoben (Dateibesitz und Berechtigungen entsprechen jetzt der Quelle, ich habe es überprüft), und da der Bootstrap fehlgeschlagen ist und ich keinen laufenden Container habe, kann ich nicht versuchen, dies wie in Update failed (postgresql) - #7 by noezDE beschrieben zu beheben.

Was ist der beste Weg, um das zu normalisieren, was PostgreSQL erwartet?

38

Können Sie die Dateien außerhalb des Containers chown? Das sollte möglich sein, wenn Sie Root-/Sudo-Berechtigungen haben.

39

Sicher, aber wozu? Von außerhalb des Containers sind die Berechtigungen sowohl korrekt als auch ergeben sie keinen Sinn.

Quelle (funktioniert):

root@ip-[...]:/var/discourse/shared/standalone# ls
total 54492
drwxr-xr-x 15 root       root         4096 Oct 22  2021 .
drwxr-xr-x  3 root       root         4096 Feb 28  2017 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Feb 28  2017 backups
-rw-r--r--  1 root       root     55730645 Mar 15  2017 discussion.json
drwx------  7 root       root         4096 Mar  6  2017 letsencrypt
drwxr-xr-x  4 root       root         4096 Feb 28  2017 log
drwxr-xr-x  2 _apt       netdev       4096 Feb 28  2017 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:39 postgres_data
drwx------ 20 _apt       netdev       4096 Oct 22  2021 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Apr  5  2018 postgres_data_older
drwxrwsr-x  5 _apt       netdev       4096 Sep 15 04:39 postgres_run
drwxr-xr-x  2 lxd        lxd          4096 Sep 16 01:03 redis_data
drwxr-xr-x  2 root       root         4096 Mar  6  2017 ssl
drwxr-xr-x  4 root       root         4096 Feb 28  2017 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:39 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Apr 13  2017 uploads

Ziel (defekt):

root@ip-[...]:/var/discourse/shared/standalone# ls -al
total 54488
drwxr-xr-x 15 root       root         4096 Sep 15 04:31 .
drwxr-xr-x  3 root       root         4096 Sep 15 04:27 ..
drwxr-xr-x  3 ubuntu     www-data     4096 Sep 15 04:27 backups
-rw-r--r--  1 root       root     55730645 Sep 15 04:27 discussion.json
drwx------  7 root       root         4096 Sep 15 04:27 letsencrypt
drwxr-xr-x  4 root       root         4096 Sep 15 04:27 log
drwxr-xr-x  2 _apt       netdev       4096 Sep 15 04:27 postgres_backup
drwx------ 19 _apt       netdev       4096 Sep 15 04:27 postgres_data
drwx------ 20 _apt       netdev       4096 Sep 15 04:30 postgres_data_old
drwx------ 20 messagebus uuidd        4096 Sep 15 04:31 postgres_data_older
drwxrwsr-x  5 messagebus tss          4096 Sep 15 04:31 postgres_run
drwxr-xr-x  2 uuidd      _ssh         4096 Sep 15 04:38 redis_data
drwxr-xr-x  2 root       root         4096 Sep 15 04:32 ssl
drwxr-xr-x  4 root       root         4096 Sep 15 04:31 state
drwxr-xr-x  4 ubuntu     www-data     4096 Sep 15 04:31 tmp
drwxr-xr-x  5 ubuntu     www-data     4096 Sep 15 04:31 uploads

Ich gehe davon aus, dass diese IDs innerhalb des Containers sinnvoller sind, vielleicht?

40

Ja, ich habe versucht, die numerischen IDs von ls -aln per Brute-Force zu ermitteln, und erhalte immer noch denselben Fehler.

2024-09-16 01:21:27.237 UTC [36] FATAL: data directory "/shared/postgres_data" has wrong ownership

Ich weiß nicht, was es will.

41

Ich glaube, ich hatte kürzlich einen ähnlichen Fehler.

Eine Vermutung ist, dass der alte Container und der neue unterschiedliche /etc/passwd-Einträge haben. Man könnte diese Dateien vergleichen, schätze ich.

Ich denke, am besten wäre es, ein Backup wiederherzustellen. Ich kann mich nicht erinnern, ob ich das getan habe oder ob ich etwas auf 777 gesetzt habe.