> For the complete documentation index, see [llms.txt](https://ayakaleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ayakaleaf-pro.ayaka.space/on-premises/de/support/support-guides/doc-version-recovery.md). # (Migration v5.0.1) Wiederherstellung der Dokumentversion {% hint style="info" %} Wenn Sie nie Server Pro Version 5.0.1 oder Community Edition Version 5.0.1 ausgeführt haben oder mit 5.0.1 eine komplett neue Instanz gestartet haben, müssen Sie diesen Wiederherstellungsprozess nicht ausführen. {% endhint %} **Aktualisierungen dieser Seite:** * (2024-04-22 13:40 BST): Schritt „Verhindern, dass neue Aktualisierungen ins System gelangen, und alle Änderungen nach MongoDB leeren“ hinzugefügt. * (2024-04-23 11:45 BST): Defekte 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 verwendeten Storage-Backend des History Stores für Chunks ab (wie definiert in `OVERLEAF_HISTORY_CHUNKS_BUCKET`). Der Wiederherstellungsprozess verzögert den Start der Anwendung innerhalb des Server-Pro-Containers. Die Website erscheint während dieser Zeit offline. Wir unterstützen die Ausführung der Wiederherstellung nur von einer einzelnen 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. Basierend auf unseren Leistungstests kann der Wiederherstellungsprozess auf moderner Hardware (3-GHz-CPU-Takt und lokaler NVMe-Speicher) ungefähr 10k kleine Projekte pro Minute verarbeiten. Als Beispiel: Planen Sie für eine Instanz mit 100k Projekten ein Wartungsfenster mit mindestens 10+2 Minuten Ausfallzeit ein. Verwenden Sie die folgende Abfrage, um die Anzahl der Projekte in Ihrer Instanz zu schätzen: {% code overflow="wrap" %} ```bash $ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()' ``` {% endcode %} Bitte lesen Sie die folgenden Wiederherstellungsschritte vollständig, bevor Sie beginnen. Kunden von Server Pro können sich gerne an wenden, wenn sie Fragen haben. ### Wiederherstellungsprozess {% stepper %} {% step %} #### Release-Images abrufen Rufen Sie die `5.0.3` Release-Images ab. {% endstep %} {% step %} #### Einige Projekte identifizieren Identifizieren Sie einige Projekte anhand der ID, bei denen der Verlauf fehlt; idealerweise haben Sie die Berechtigung, an einem davon eine Änderung vorzunehmen. {% endstep %} {% step %} #### Wartung planen Planen Sie ein Wartungsfenster für die Ausfallzeit ein. {% endstep %} {% step %} #### Alle außer einem Worker stoppen Stoppen Sie bei einer horizontalen Skalierung alle Worker bis auf einen. {% endstep %} {% step %} #### Neue Aktualisierungen stoppen und alle Änderungen nach MongoDB leeren Verhindern Sie, dass neue Aktualisierungen ins System gelangen, und leeren Sie alle Änderungen nach MongoDB: 1. Schließen Sie den Editor und trennen Sie alle Benutzer manuell über das Admin-Panel auf `https://my-server-pro.example.com/admin#open-close-editor` im Tab „Editor öffnen/schließen“. 2. Stoppen Sie den Websocket-/Echtzeitdienst. ```bash $ docker exec sharelatex sv stop real-time-overleaf ``` 3. Warten Sie, bis der Echtzeitdienst beendet wurde, erkennbar an `down:`. ```bash $ docker exec sharelatex sv status real-time-overleaf run: real-time-sharelatex: (pid 394) 50s, want down, got TERM # noch etwas länger warten... $ docker exec sharelatex sv status real-time-overleaf down: real-time-sharelatex: 7s, normally up ``` 4. Stoppen Sie den git-bridge-Container, falls aktiviert. ```bash $ docker stop git-bridge ``` 5. Wenn Sie 5.0.2 nie ausgeführt haben: Führen Sie einen manuellen Flush für Dokumentaktualisierungen aus und warten Sie, bis er erfolgreich abgeschlossen ist. Sie können den Befehl bei Fehler wiederholen. Falls Sie bei aufeinanderfolgenden Durchläufen einen von null verschiedenen `failureCount` sehen, stoppen Sie bitte die Migration (stellen Sie die Dienste über `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}
   Alle Projekte wurden geleert
6. Wenn Sie 5.0.2 nie ausgeführt haben: Stellen Sie sicher, dass alle Änderungen aus Redis geleert wurden. Wenn Sie eine Ausgabe von `redis-cli`, stoppen Sie bitte die Migration (stellen Sie die Dienste über `docker restart git-bridge sharelatex`) wieder her und wenden Sie sich an den Support. 
$ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
   # keine Ausgabe von redis-cli bedeutet Erfolg, überprüfen Sie als Nächstes den Exit-Code von redis-cli; er sollte null sein
   $ echo $?
   0
7. Versuchen Sie, ausstehende Verlaufänderungen zu leeren. Dies muss ein bestmöglicher Flush sein, da einige Projekte aufgrund der fehlerhaften Datenbankmigration beschädigte Verläufe 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 /
{% endstep %} {% step %} #### Ein Backup erstellen Erwägen Sie, ein [konsistentes Backup](https://docs.overleaf.com/on-premises/maintenance/data-and-backups#performing-a-consistent-backup) Backup der Instanz anzulegen. {% endstep %} {% step %} #### Aktualisieren Aktualisieren auf Version `5.0.3`. {% endstep %} {% step %} #### Automatische Wiederherstellung Der Wiederherstellungsprozess wird beim Start des Containers automatisch ausgeführt. {% endstep %} {% step %} #### Fortschritt verfolgen Sie können den Fortschritt des Skripts verfolgen, indem Sie die Logdatei `/var/lib/overleaf/data/history/doc-version-recovery.log`. lesen. Zu Beginn wird die Gesamtzahl der Projekte ausgegeben und nach jeweils 1000 verarbeiteten Projekten eine Zusammenfassung. {% code overflow="wrap" %} ```bash $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers ``` {% endcode %} {% endstep %} {% step %} #### Warten Sie, bis der Wiederherstellungsprozess abgeschlossen ist Warten Sie, bis der Wiederherstellungsprozess abgeschlossen ist, indem Sie entweder die oben genannte Logdatei verfolgen, bis eine `Abgeschlossen.` Zeile ausgegeben wurde, oder warten Sie darauf, dass `Wiederherstellung der Dokumentversionen abgeschlossen.` in der Standardausgabe des Server-Pro-Containers ausgegeben wird. {% endstep %} {% step %} #### Wiederherstellungsprozess validieren Validieren Sie den Wiederherstellungsprozess, indem Sie den Verlaufbereich für einige der Projekte öffnen, bei denen zuvor der Verlauf fehlte. 1. Beschleunigen Sie die erneute Synchronisierung für die zu testenden Projekte (sie werden ohnehin irgendwann 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 der zu testenden Projekt-IDs, ersetzen Sie `000000000000000000000000` jeweils nur eine Projekt-ID. 2. Öffnen Sie den Projekt-Editor für die Projekte `https://my-server-pro.example.com/project/000000000000000000000000` 3. Öffnen Sie den Bereich „Verlauf“ für das Projekt und sehen Sie sich den neuesten Inhalt an. 4. Optional: Schließen Sie den Bereich „Verlauf“ wieder. Nehmen Sie eine Codeänderung vor, z. B. indem Sie dem Header einen Kommentar hinzufügen. 5. Optional: Führen Sie einen erneuten Kompilierungsvorgang aus, um einen Flush der lokalen Änderung auszulösen. Öffnen Sie den Bereich „Verlauf“ erneut und sehen Sie sich die Änderung an. Wenn Sie fertig sind, machen Sie die Änderung rückgängig. {% endstep %} {% step %} #### Für horizontale Skalierung... Starten Sie die anderen Worker erneut. {% endstep %} {% step %} #### Lassen Sie die Instanz weiterlaufen Bitte lassen Sie die Instanz weiterlaufen, die den Wiederherstellungsprozess ausgeführt hat. Sie wird den Verlauf für alle Projekte im Hintergrund mit einer Parallelität von 1 erneut synchronisieren. Dadurch entsteht eine leicht erhöhte Grundlast. (Sie können die Instanz neu starten, aber dann muss sie die erneuten Synchronisierungen von vorn beginnen.) {% endstep %} {% step %} #### Teilen Sie uns mit, wenn Sie fertig sind Server Pro-Kunden: Bitte informieren Sie das Support-Team, wenn Sie den Wiederherstellungsprozess abgeschlossen haben. {% endstep %} {% endstepper %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://ayakaleaf-pro.ayaka.space/on-premises/de/support/support-guides/doc-version-recovery.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.