Skip to main content

Migrering af fuld projekthistorik

Version 3.5.x af Community Edition indeholder funktionen Full Project History, som allerede er tilgængelig i vores SaaS-tilbud, overleaf.com Når du har opgraderet din instans til Overleaf CE 3.5.13, vil alle nye projekter som standard bruge Full Project History. Eksisterende projekter fortsætter med at bruge det ældre historiksystem, indtil de bliver migreret.
Hvis du opgraderer til 3.5.13 og beslutter dig for at nedgradere til en tidligere version, skal du gendanne fra en fuld systemsikkerhedskopi. Historikken for projekter, der er oprettet i 3.5.13, er ikke kompatibel med tidligere versioner af Overleaf CE.
Den nye Full Project History giver brugerne flere forbedringer:
  • Den sporer ændringer i binære filer, hvilket ikke understøttes i det ældre system.
  • Der er understøttelse af navngivne versioner.
  • Systemet er generelt mere robust, og der er mindre risiko for datatab.
Se dokumentationen til Full Project History for at få flere oplysninger om fuld projekthistorik.

Migrering af eksisterende projekter

1

Opret en sikkerhedskopi

Opret en fuld sikkerhedskopi af din instans med et konsistent snapshot af mapperne mongo, redis og sharelatex.
2

Opdater

Opdater versionen af sharelatex/sharelatex-imaget til 3.5.13.Toolkit: Brug scriptet $ bin/upgrade til at opgradere Toolkit til den nyeste version, og ret config/version til 3.5.13.
3

Start instansen

Ideelt set bør du forhindre brugerne i at tilgå din instans, mens migreringen finder sted, for at undgå datatab, hvis du skulle få brug for at gendanne din sikkerhedskopi. Se Offline migration for at få flere oplysninger om, hvordan du gør dette.
4

Vent, til alle tjenester kører

Vent, til alle tjenester er startet og kører (se kommandoen nedenfor)
5

Kør migreringsscriptet

--force-clean rydder delvist migrerede projekthistorikdata i det nye system, så migreringen kan forsøges igen for enkelte projekter, der mislykkedes i tidligere forsøg;--fix-invalid-characters erstatter ikke-udskrivbare tegn, der ikke understøttes af det nye historiksystem;--convert-large-docs-to-file konverterer dokumenter, der overskrider grænsen på 2 MB for redigerbar størrelse, til en ikke-redigerbar fil)Outputtet bør se således ud:
Hvis migreringen lykkes, får du exitkoden 0, og de sidste linjer viser, at der ikke var nogen fejl:
Du kan genåbne adgangen for dine brugere (se næste trin). Hvis der er fejl, så se fejlfindingsafsnittet nedenfor. Du kan stadig genåbne siden, selvom problemerne ikke bliver løst med det samme, og de projekter, der ikke er migreret, forbliver på det ældre historiksystem.
6

Genåbn siden

Hvis du har valgt at udføre en offline-migrering, skal du genåbne siden. Hvis du stadig er logget ind, skal du:
  1. Klikke på knappen Admin og vælge Manage Site
  2. Klikke på fanen Open/Close Editor
  3. Klikke på knappen Reopen Editor
Hvis du har lukket din browser, skal du genstarte siden med $ bin/up.

Offline-migrering

For at forhindre brugerne i at logge ind, mens scriptet til migrering af historik kører, skal du følge disse trin:
  • Log ind på din Overleaf-instans med en administratorkonto
  • Klik på knappen Admin, og vælg Manage Site
  • Klik på fanen Open/Close Editor
  • Klik på knappen Close Editor
  • Klik på knappen Disconnect all users
Når dette er gjort, vil brugere, der er logget ind, blive omdirigeret til vedligeholdelsessiden, og nye brugere, der besøger login-siden, vil se vedligeholdelsessiden og vil ikke kunne logge ind.

Online-migrering

Det er muligt at køre migreringsscriptene, mens applikationen stadig kører. Der er et par forhold, du skal tage højde for:
  • Migreringsprocessen er CPU-intensiv, så du bør overvåge ressourceforbruget, mens scriptet kører.
  • Med en høj --concurrency-værdi kan event-loopet i nogle tjenester (især track-changes) blive blokeret i perioder, hvilket vil give en forringet brugeroplevelse. Vi anbefaler at starte med standardværdien --concurrency=1.
  • Du kan til enhver tid stoppe scriptet. Starter du det igen, genoptages migreringen, hvor du slap. Det er nyttigt, hvis du foretrækker at køre migreringen i mindre travle timer (f.eks. om natten).
Vores anbefaling er at lukke siden og køre migreringen offline i et vedligeholdelsesvindue, når dit antal projekter er under 1000 (db.projects.count()). Hvis antallet af projekter er stort, kan du køre scriptet og overvåge dets fremskridt og derefter beslutte, om du vil fortsætte online eller offline ud fra din konkrete situation.

Oprydning i ældre historikdata

Et script til oprydning i ældre historikdata blev tilføjet i Server Pro 3.5.6, 4.0.6 og 4.1.0.
Scriptet kan køres, når alle projekterne er blevet migreret. Det kan også bruges til at frigøre noget plads under en online-migrering.
I Server Pro før version 3.5.13 sletter scriptet indholdet af samlingerne docHistory og docHistoryIndex. MongoDB frigiver ikke diskplads, når du sletter dokumenter; i stedet genbruges pladsen til fremtidige dokumenter i den samme samling. Intet vil skrive til disse samlinger igen efter historikmigreringen, så diskpladsen forbliver ubrugt.Hvis du vil gøre diskpladsen tilgængelig igen, kan du opgradere til Server Pro 3.5.13 (hvis du stadig bruger 3.x-udgaven) eller Server Pro 4.2.5 (hvis du bruger 4.x-udgaven) og køre oprydningsscriptet igen.Oprydningsscriptet, som det er inkluderet i de seneste patch-udgivelser af Server Pro 3.5.x og den seneste 4.x.x, sletter samlingerne som sidste trin.Det er sikkert at køre oprydningsscriptet igen.

Fejlfinding

Vi vil tilføje råd om fejlfinding her. Bemærk, at selvom vi normalt kun tilbyder support til Server Pro-kunder, vil vi i betragtning af denne migrerings karakter også gøre vores bedste for at hjælpe CE-kunder, der oplever problemer, som er specifikke for migreringen af fuld projekthistorik. Hvis scriptet til migrering af fuld projekthistorik mislykkes (dvs. afsluttes med en fejl eller udskriver et antal mislykkede projekter, der ikke er nul), så send følgende oplysninger til vores supportteam via e-mail support+historymigration@overleaf.com med angivelse af: Emne: Full project history migration problem
  • Instanstype: CE eller Server Pro (slet det, der ikke passer)
  • Installationstype: Overleaf Toolkit eller docker-compose.yml eller andet (slet det, der ikke passer)
  • Version: 3.5.x (Toolkit: $ cat config/version)
  • Output fra migreringsscriptet (som bør ligge i containeren under /overleaf/services/web)
  • Migrated Projects: (ifølge migreringsscriptets output)
  • Total Projects: (ifølge migreringsscriptets output)
  • Remaining Projects: (ifølge migreringsscriptets output)
  • Migreringens varighed:
  • Output fra bin/doctor (når Toolkit bruges)
  • Toolkit-version: $ git rev-parse HEAD (når Toolkit bruges)
Overvej at vedhæfte logfilerne for tjenesterne history-v1, project-history og track-changes til e-mailen. Du kan finde dem i /var/log/sharelatex inde i sharelatex-containeren og eksportere dem på denne måde:
Fjern venligst alle følsomme oplysninger fra logfilerne, før du vedhæfter dem.

Find ødelagte filtræer

Migreringen kan mislykkes for projekter med et forkert udformet filtræ (f.eks. hvor filnavne er tomme). Du kan finde en liste over disse problemer med scriptet find_malformed_filetrees, som kontrollerer alle projekter i databasen:
For at rette de ugyldige stier skal du bruge scriptet fix_malformed_filetree og køre kommandoen én gang for hver ugyldig sti:

Nedgradering af projekter fra fuld projekthistorik til ældre historik

Hvis et projekt er blevet migreret til fuld projekthistorik, men du ønsker at vende tilbage til den ældre historik, skal du bruge scriptet downgrade_project på følgende måde:
Sidst ændret 4. oktober 2026