Migration des vollständigen Projektverlaufs
Das Release3.5.x der Community Edition enthält die Funktion Full Project History, die in unserem SaaS-Angebot overleaf.com bereits verfügbar ist
Nach dem Upgrade Ihrer Instanz auf Overleaf CE 3.5.13 verwenden alle neuen Projekte standardmäßig Full Project History. Bestehende Projekte nutzen weiterhin das alte Verlaufssystem, bis sie migriert werden.
Wenn Sie auf
3.5.13 upgraden und sich anschließend für ein Downgrade auf eine frühere Version entscheiden, sollten Sie ein vollständiges System-Backup wiederherstellen. Der Verlauf von in 3.5.13 erstellten Projekten ist nicht mit früheren Versionen von Overleaf CE kompatibel.- Er verfolgt Änderungen an Binärdateien, was im alten System nicht unterstützt wird.
- Benannte Versionen (Labels) werden unterstützt.
- Das System ist insgesamt robuster, und das Risiko von Datenverlust ist geringer.
Bestehende Projekte migrieren
1
Backup erstellen
Erstellen Sie ein vollständiges Backup Ihrer Instanz mit einem konsistenten Snapshot der Verzeichnisse mongo, redis und sharelatex.
2
Aktualisieren
Aktualisieren Sie die Version des Images sharelatex/sharelatex auf 3.5.13.Toolkit: Verwenden Sie das Skript
$ bin/upgrade, um das Toolkit auf die neueste Version zu aktualisieren, und setzen Sie config/version auf 3.5.13.3
Instanz starten
Idealerweise sollten Sie verhindern, dass Benutzer während der Migration auf Ihre Instanz zugreifen, um Datenverlust zu vermeiden, falls Sie Ihr Backup wiederherstellen müssen. Weitere Informationen dazu finden Sie unter Offline-Migration.
4
Warten, bis alle Dienste laufen
Warten Sie, bis alle Dienste gestartet sind und laufen (siehe Befehl unten)
5
Migrationsskript ausführen
--force-clean entfernt teilweise migrierte Projektverlaufsdaten im neuen System; dadurch kann die Migration für einzelne Projekte, die bei früheren Versuchen fehlgeschlagen sind, erneut versucht werden;--fix-invalid-characters ersetzt nicht druckbare Zeichen, die vom neuen Verlaufssystem nicht unterstützt werden;--convert-large-docs-to-file wandelt Dokumente, die den Schwellenwert von 2 MB für bearbeitbare Dateien überschreiten, in eine nicht bearbeitbare Datei um)Die Ausgabe sollte etwa so aussehen:0, und die letzten Zeilen zeigen an, dass keine Fehler aufgetreten sind:6
Website wieder öffnen
Wenn Sie sich für eine Offline-Migration entschieden haben, müssen Sie die Website wieder öffnen. Wenn Sie noch angemeldet sind, gehen Sie wie folgt vor:
- Klicken Sie auf die Schaltfläche Admin und wählen Sie Manage Site
- Klicken Sie auf den Tab Open/Close Editor
- Klicken Sie auf die Schaltfläche Reopen Editor
$ bin/up neu starten.Offline-Migration
Um zu verhindern, dass sich Benutzer anmelden können, während das Skript zur Verlaufsmigration läuft, gehen Sie wie folgt vor:- Melden Sie sich mit einem Administratorkonto bei Ihrer Overleaf-Instanz an
- Klicken Sie auf die Schaltfläche Admin und wählen Sie Manage Site
- Klicken Sie auf den Tab Open/Close Editor
- Klicken Sie auf die Schaltfläche Close Editor
- Klicken Sie auf die Schaltfläche Disconnect all users
Online-Migration
Es ist möglich, die Migrationsskripte auszuführen, während die Anwendung weiterläuft. Dabei gibt es einige Punkte zu beachten:- Der Migrationsprozess ist CPU-intensiv; Sie sollten die Ressourcennutzung überwachen, während das Skript läuft.
- Bei einem hohen
--concurrency-Wert kann die Event-Loop in einigen Diensten (insbesonderetrack-changes) blockiert werden, was zu einer schlechteren Benutzererfahrung führt. Wir empfehlen, mit dem Standardwert--concurrency=1zu beginnen. - Sie können das Skript jederzeit stoppen. Ein erneuter Start setzt die Migration an der Stelle fort, an der sie unterbrochen wurde. Das ist nützlich, wenn Sie die Migration lieber zu weniger ausgelasteten Zeiten (z. B. nachts) ausführen möchten.
db.projects.count()). Bei einer großen Anzahl von Projekten können Sie das Skript ausführen, den Fortschritt beobachten und dann je nach Ihrer Situation entscheiden, ob Sie es online oder offline weiterlaufen lassen.
Alte Verlaufsdaten bereinigen
Ein Skript zur Bereinigung alter Verlaufsdaten wurde in Server Pro3.5.6, 4.0.6 und 4.1.0 hinzugefügt.
In Server Pro vor Version 3.5.13 löscht das Skript den Inhalt der Collections
docHistory und docHistoryIndex. MongoDB gibt nach dem Löschen von Dokumenten keinen Speicherplatz frei, sondern verwendet diesen Platz für zukünftige Dokumente in derselben Collection wieder. Nach der Verlaufsmigration wird nichts mehr in diese Collections geschrieben, sodass der Speicherplatz ungenutzt bleibt.Wenn Sie den Speicherplatz wieder verfügbar machen möchten, können Sie auf Server Pro 3.5.13 (wenn Sie noch das 3.x-Release verwenden) oder Server Pro 4.2.5 (wenn Sie das 4.x-Release verwenden) upgraden und das Bereinigungsskript erneut ausführen.Das in den neuesten Patch-Releases von 3.5.x und den neuesten 4.x.x-Versionen von Server Pro enthaltene Bereinigungsskript löscht die Collections als letzten Schritt.Das Bereinigungsskript kann gefahrlos erneut ausgeführt werden.Fehlerbehebung
Wir werden hier Hinweise zur Fehlerbehebung ergänzen. Bitte beachten Sie: Obwohl wir normalerweise nur Server Pro-Kunden Support anbieten, werden wir aufgrund der Art dieser Migration auch CE-Nutzer nach besten Kräften unterstützen, die Probleme speziell mit der Migration des vollständigen Projektverlaufs haben. Wenn das Skript zur Migration des vollständigen Projektverlaufs fehlschlägt (d. h. mit einem Fehler beendet wird oder eine von null verschiedene Anzahl fehlgeschlagener Projekte ausgibt), senden Sie bitte die folgenden Angaben per E-Mail an unser Support-Team support+historymigration@overleaf.com: Betreff: Full project history migration problem- Instanztyp: CE oder Server Pro (Nichtzutreffendes streichen)
- Installationstyp: Overleaf Toolkit,
docker-compose.ymloder andere (Nichtzutreffendes streichen) - Version: 3.5.x (Toolkit:
$ cat config/version) - Ausgabe des Migrationsskripts (sollte sich im Container unter
/overleaf/services/webbefinden) - Migrierte Projekte: (laut Ausgabe des Migrationsskripts)
- Projekte insgesamt: (laut Ausgabe des Migrationsskripts)
- Verbleibende Projekte: (laut Ausgabe des Migrationsskripts)
- Dauer der Migration:
- Ausgabe von
bin/doctor(bei Verwendung des Toolkits) - Toolkit-Version:
$ git rev-parse HEAD(bei Verwendung des Toolkits)
history-v1, project-history und track-changes beizufügen. Sie finden diese unter /var/log/sharelatex im Container sharelatex und können sie wie folgt exportieren:
Fehlerhafte Dateibäume finden
Die Migration kann bei Projekten mit einem fehlerhaften Dateibaum fehlschlagen (z. B. wenn Dateinamen leer sind). Eine Liste dieser Probleme erhalten Sie mit dem Skriptfind_malformed_filetrees, das alle Projekte in der Datenbank überprüft:
fix_malformed_filetree und führen den Befehl für jeden fehlerhaften Pfad einmal aus:
Projekte vom vollständigen Projektverlauf auf den alten Verlauf zurückstufen
Wenn ein Projekt bereits auf den vollständigen Projektverlauf migriert wurde, Sie aber zum alten Verlauf zurückkehren möchten, verwenden Sie das Skriptdowngrade_project wie folgt:

