(v5.0.1-Migration) Wiederherstellung von Dokumentversionen

Wenn Sie nie Server Pro Version 5.0.1 oder Community Edition Version 5.0.1 betrieben haben oder eine komplett neue Instanz mit 5.0.1 gestartet haben, müssen Sie diesen Wiederherstellungsprozess nicht ausführen.

• (2024-04-22 13:40 BST): Schritt „Neue Updates am Eindringen in das System hindern und alle Änderungen nach MongoDB flushen” hinzugefügt.
• (2024-04-23 11:45 BST): Fehlerhafte Flushes in 5.0.1 berücksichtigt und Flushes übersprungen, wenn 5.0.2 gestartet wurde.

Die Dauer der Wiederherstellung hängt von der Anzahl und Größe der Projekte in Ihrer Instanz sowie vom Speicher-Backend ab, das der History Store für Chunks verwendet (wie in OVERLEAF_HISTORY_CHUNKS_BUCKET definiert).

Der Wiederherstellungsprozess verzögert den Anwendungsstart im Server-Pro-Container. Die Website erscheint in dieser Zeit offline. Wir unterstützen die Wiederherstellung nur aus einer einzigen Instanz des Server-Pro-Containers; alle anderen Worker für horizontale Skalierung müssen offline sein.

Sie können den Wiederherstellungsprozess bei Bedarf anhalten und fortsetzen.

Laut unseren Performance-Tests kann der Wiederherstellungsprozess auf moderner Hardware (3 GHz CPU-Takt und lokaler NVMe-Speicher) etwa 10.000 kleine Projekte pro Minute verarbeiten. Planen Sie beispielsweise für eine Instanz mit 100.000 Projekten ein Wartungsfenster mit mindestens 10+2 Minuten Ausfallzeit ein. Mit der folgenden Abfrage können Sie die Anzahl der Projekte in Ihrer Instanz schätzen:

$ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()'

Bitte lesen Sie die folgenden Wiederherstellungsschritte vollständig durch, bevor Sie beginnen. Server-Pro-Kunden können sich bei Fragen jederzeit gerne an [e-mail] wenden.

​

Wiederherstellungsprozess

1. Release-Images herunterladen

   Laden Sie die Release-Images 5.0.3 herunter.

2. Einige Projekte identifizieren

   Identifizieren Sie anhand ihrer ID einige Projekte, denen der Verlauf fehlt; idealerweise haben Sie die Berechtigung, an einem davon eine Änderung vorzunehmen.

3. Wartung planen

   Planen Sie ein Wartungsfenster für die Ausfallzeit ein.

4. Alle Worker bis auf einen stoppen

   Stoppen Sie bei einem Setup mit horizontaler Skalierung alle Worker bis auf einen.

5. Neue Updates stoppen und alle Änderungen nach MongoDB flushen

   Verhindern Sie, dass neue Updates in das System gelangen, und flushen Sie alle Änderungen nach MongoDB:

   1. Schließen Sie den Editor und trennen Sie alle Benutzer manuell über das Admin-Panel unter https://my-server-pro.example.com/admin#open-close-editor im Tab „Open/Close Editor”.

   2. Stoppen Sie den Websocket-/Echtzeitdienst.

      $ docker exec sharelatex sv stop real-time-overleaf
      

   3. Warten Sie, bis der Echtzeitdienst beendet ist, erkennbar an down:.

      $ docker exec sharelatex sv status real-time-overleaf
      run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
      # wait a little longer...
      
      $ docker exec sharelatex sv status real-time-overleaf
      down: real-time-sharelatex: 7s, normally up
      

   4. Stoppen Sie den git-bridge-Container, falls aktiviert.

      $ docker stop git-bridge
      

   5. Falls Sie nie 5.0.2 betrieben haben: Lösen Sie einen manuellen Flush der Dokumentaktualisierungen aus und warten Sie, bis er erfolgreich abgeschlossen ist.

      Bei einem Fehler können Sie den Befehl wiederholen. Wenn Sie bei aufeinanderfolgenden Durchläufen einen failureCount ungleich null sehen, brechen Sie die Migration bitte ab (stellen Sie die Dienste mit docker restart git-bridge sharelatex wieder her) und wenden Sie sich an den Support.

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /etc/overleaf/env.sh && cd services/document-updater && LOG_LEVEL=info node scripts/flush_all.js'
          ...
          {"name":"default","hostname":"...","pid":324,"level":30,"successCount":...,"failureCount":0,"msg":"finished flushing all projects","time":"...","v":0}
          Done flushing all projects
          
      

   6. Falls Sie nie 5.0.2 betrieben haben: Stellen Sie sicher, dass alle Änderungen aus Redis geflusht wurden.

      Wenn redis-cli eine Ausgabe liefert, brechen Sie die Migration bitte ab (stellen Sie die Dienste mit docker restart git-bridge sharelatex wieder her) und wenden Sie sich an den Support.

      $ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
          # no output from redis-cli indicates success, check exit code of redis-cli next, it should be zero
          $ echo $?
          0
          
      

   7. Versuchen Sie, alle ausstehenden Verlaufsänderungen zu flushen.

      Dies ist ein Best-Effort-Flush, da einige Projekte aufgrund der fehlerhaften Datenbankmigration einen beschädigten Verlauf haben. Alle Fehler werden am Ende des Wiederherstellungsprozesses durch eine erneute Synchronisierung des Verlaufs behoben.

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /
          
      
6. Backup erstellen

   Erwägen Sie, ein konsistentes Backup der Instanz zu erstellen.

7. Upgrade durchführen

   Führen Sie ein Upgrade auf Version 5.0.3 durch.

8. Automatische Wiederherstellung

   Der Wiederherstellungsprozess wird beim Start des Containers automatisch ausgeführt.

9. Fortschritt verfolgen

   Sie können den Fortschritt des Skripts verfolgen, indem Sie die Logdatei /var/lib/overleaf/data/history/doc-version-recovery.log mit tail beobachten. Zu Beginn wird die Gesamtzahl der Projekte ausgegeben und danach nach jeweils 1000 verarbeiteten Projekten eine Zusammenfassung.

   $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
   
10. Auf den Abschluss der Wiederherstellung warten

    Warten Sie, bis der Wiederherstellungsprozess abgeschlossen ist – entweder indem Sie die obige Logdatei verfolgen, bis eine Zeile Done. ausgegeben wird, oder indem Sie warten, bis Finished recovery of doc versions. in der Standardausgabe des Server-Pro-Containers erscheint.

11. Wiederherstellung überprüfen

    Überprüfen Sie den Wiederherstellungsprozess, indem Sie den Verlaufsbereich für einige der Projekte öffnen, denen zuvor der Verlauf fehlte.

    1. Beschleunigen Sie die erneute Synchronisierung der zu testenden Projekte. (Sie werden irgendwann ohnehin verarbeitet, aber wir möchten nicht warten, bis sie an der Reihe sind.)

       $ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true"
           
       

       (Wiederholen Sie dies für jede zu testende Projekt-ID und ersetzen Sie 000000000000000000000000 jeweils durch eine Projekt-ID.)

    2. Öffnen Sie den Projekteditor für die Projekte unter https://my-server-pro.example.com/project/000000000000000000000000.

    3. Öffnen Sie den Bereich „History” des Projekts und prüfen Sie den neuesten Inhalt.

    4. Optional: Schließen Sie den Bereich „History” wieder. Nehmen Sie eine Codeänderung vor, etwa indem Sie im Header einen Kommentar hinzufügen.

    5. Optional: Lösen Sie eine erneute Kompilierung aus, um einen Flush der lokalen Änderung anzustoßen. Öffnen Sie den Bereich „History” erneut und prüfen Sie die Änderung. Machen Sie die Änderung anschließend rückgängig.

12. Bei horizontaler Skalierung...

    Starten Sie die anderen Worker wieder.

13. Instanz weiterlaufen lassen

    Lassen Sie die Instanz, die den Wiederherstellungsprozess ausgeführt hat, bitte weiterlaufen. Sie synchronisiert den Verlauf aller Projekte im Hintergrund mit einer Parallelität von 1 neu. Dies führt zu einer leicht erhöhten Grundlast. (Sie können die Instanz neu starten, die erneuten Synchronisierungen beginnen dann jedoch von vorn.)

14. Geben Sie uns Bescheid, wenn Sie fertig sind

    Server-Pro-Kunden: Bitte informieren Sie das Support-Team, sobald Sie den Wiederherstellungsprozess abgeschlossen haben.