(Migrering i v3.5.13) Migrering til full prosjekthistorikk

​

Migrering til full prosjekthistorikk

Utgivelsen 3.5.x av Community Edition inkluderer funksjonen Full Project History som allerede er tilgjengelig i vårt SaaS-tilbud, overleaf.com

Etter at du har oppgradert instansen til Overleaf CE 3.5.13, vil alle nye prosjekter bruke Full Project History som standard. Eksisterende prosjekter fortsetter å bruke det eldre historikksystemet til de blir migrert.

Hvis du oppgraderer til 3.5.13 og bestemmer deg for å nedgradere til en tidligere versjon, bør du gjenopprette fra en fullstendig sikkerhetskopi av systemet. Historikken for prosjekter opprettet i 3.5.13 er ikke kompatibel med tidligere versjoner av Overleaf CE.

Den nye Full Project History gir flere forbedringer for brukerne:

• Den sporer endringer i binærfiler, noe som ikke støttes i det eldre systemet.
• Det er støtte for merkede versjoner.
• Systemet er generelt mer robust, og risikoen for datatap er mindre.

Se dokumentasjonen for Full Project History for mer informasjon om full prosjekthistorikk.

​

Migrere eksisterende prosjekter

1. Ta en sikkerhetskopi

   Ta en fullstendig sikkerhetskopi av instansen din med et konsistent øyeblikksbilde av katalogene mongo, redis og sharelatex.

2. Oppdater

   Oppdater versjonen av sharelatex/sharelatex-imaget til 3.5.13.

   Toolkit: Bruk skriptet $ bin/upgrade for å oppgradere Toolkit til nyeste versjon, og endre config/version til 3.5.13.

3. Start instansen

   Ideelt sett bør du hindre brukere i å få tilgang til instansen mens migreringen pågår, for å unngå datatap i tilfelle du må gjenopprette sikkerhetskopien. Se Frakoblet migrering for mer informasjon om hvordan du gjør dette.

4. Vent til alle tjenester er oppe og kjører

   Vent til alle tjenester er oppe og kjører (se kommandoen nedenfor)

   $ bin/docker-compose exec sharelatex /bin/bash -c "curl http://localhost:3000/status"
   web sharelatex is alive (api)%
   
5. Kjør migreringsskriptet

   # Overleaf Toolkit users:
   $ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file"
   
   # legacy docker-compose.yml users:
   $ docker exec sharelatex /bin/bash -c "cd /overleaf/services/web; VERBOSE_LOGGING=true node scripts/history/migrate_history.js --force-clean --fix-invalid-characters --convert-large-docs-to-file"
   

   --force-clean fjerner delvis migrerte data for prosjekthistorikk i det nye systemet, noe som gjør det mulig å prøve migreringen på nytt for enkeltprosjekter som mislyktes i tidligere forsøk;

   --fix-invalid-characters erstatter ikke-utskrivbare tegn som ikke støttes av det nye historikksystemet;

   --convert-large-docs-to-file konverterer dokumenter som er over grensen på 2MB for redigerbar størrelse, til en ikke-redigerbar fil)

   Utdataene skal se slik ut:

   Migrated Projects  :  1
   Total Projects     :  51
   Remaining Projects :  51
   Total history records to migrate: 98
   Starting migration...
   Migrating project: 63d29b5772dd80015a81bffe
   migration result { upgraded: true, historyType: 'NoneWithoutConversion' }
   Migrating project: 63d29c2e72dd80015a81c0a2
   migration result { upgraded: true, historyType: 'NoneWithoutConversion' }
   
   // …
   
   Migration complete
   ==================
   Projects migrated:  51
   Projects failed:  0
   Done.
   

   Hvis migreringen er vellykket, får du avslutningskoden 0, og de siste linjene viser at ingen prosjekter mislyktes:

   Projects failed:  0
   Done.
   

   Du kan åpne tilgangen for brukerne igjen (se neste trinn). Hvis noe mislyktes, se feilsøkingsavsnittet nedenfor. Du kan likevel åpne nettstedet igjen hvis problemene ikke løses umiddelbart, og prosjektene som ikke er migrert, vil fortsette å bruke det eldre historikksystemet.

6. Åpne nettstedet igjen

   Hvis du valgte å utføre en frakoblet migrering, må du åpne nettstedet igjen. Hvis du fortsatt er logget inn, må du:

   1. Klikke på knappen Admin og velge Manage Site
   2. Klikke på fanen Open/Close Editor
   3. Klikke på knappen Reopen Editor

   Hvis du har lukket nettleseren, må du starte nettstedet på nytt med $ bin/up.

​

Frakoblet migrering

For å hindre brukere i å logge inn mens migreringsskriptet for historikk kjører, følger du disse trinnene:

• Logg inn på Overleaf-instansen din med en administratorkonto
• Klikk på knappen Admin og velg Manage Site
• Klikk på fanen Open/Close Editor
• Klikk på knappen Close Editor
• Klikk på knappen Disconnect all users

Når dette er gjort, blir alle innloggede brukere omdirigert til vedlikeholdssiden, og nye brukere som besøker innloggingssiden, vil se vedlikeholdssiden og vil ikke kunne logge inn.

​

Tilkoblet migrering

Det er mulig å kjøre migreringsskriptene mens applikasjonen fortsatt kjører. Det er noen forhold du bør ta hensyn til:

• Migreringsprosessen er CPU-intensiv, så du bør overvåke ressursbruken mens skriptet kjører.
• Med en høy verdi for --concurrency kan hendelsesløkken i enkelte tjenester (særlig track-changes) bli blokkert, noe som kan gi en dårligere brukeropplevelse. Vi anbefaler å starte med standardverdien --concurrency=1.
• Du kan stoppe skriptet når som helst. Når du starter det igjen, fortsetter migreringen der du slapp. Dette er nyttig hvis du foretrekker å kjøre migreringen i mindre travle timer (f.eks. om natten).

Vår anbefaling er å stenge nettstedet og kjøre migreringen frakoblet i et vedlikeholdsvindu når du har færre enn 1000 prosjekter (db.projects.count()). Hvis antallet prosjekter er stort, kan du kjøre skriptet og overvåke fremdriften, og deretter avgjøre om du vil fortsette å kjøre det tilkoblet eller frakoblet ut fra din situasjon.

​

Rydde opp i data fra den eldre historikken

Et skript for å rydde opp i data fra den eldre historikken ble lagt til i Server Pro 3.5.6, 4.0.6 og 4.1.0.

bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/history/clean_sl_history_data.js"

Skriptet kan kjøres etter at alle prosjektene er migrert. Det kan også brukes til å frigjøre plass mens du utfører en tilkoblet migrering.

I Server Pro før versjon 3.5.13 sletter skriptet innholdet i samlingene docHistory og docHistoryIndex. MongoDB frigjør ikke diskplass etter at du har slettet dokumenter; i stedet gjenbrukes plassen til fremtidige dokumenter i samme samling. Ingenting vil skrive til disse samlingene igjen etter historikkmigreringen, så diskplassen vil forbli ubrukt.

Hvis du vil gjøre diskplassen tilgjengelig igjen, kan du oppgradere til Server Pro 3.5.13 (hvis du fortsatt bruker 3.x-utgivelsen) eller Server Pro 4.2.5 (hvis du bruker 4.x-utgivelsen) og kjøre oppryddingsskriptet på nytt.

Oppryddingsskriptet som følger med de nyeste patchutgivelsene av Server Pro 3.5.x og nyeste 4.x.x, sletter samlingene som siste trinn.

Det er trygt å kjøre oppryddingsskriptet på nytt.

​

Feilsøking

Vi vil legge til råd om feilsøking her. Merk at selv om vi vanligvis bare tilbyr støtte til Server Pro-kunder, vil vi på grunn av denne migreringens natur også gjøre vårt beste for å hjelpe CE-kunder som opplever problemer som er spesifikke for migreringen til full prosjekthistorikk.

Hvis migreringsskriptet for full prosjekthistorikk mislykkes (dvs. avsluttes med en feil eller skriver ut et antall mislykkede prosjekter som ikke er null), send følgende opplysninger til supportteamet vårt på e-post [e-mail], med følgende detaljer:

Emne: Full project history migration problem

• Instanstype: CE eller Server Pro (stryk det som ikke passer)
• Installasjonstype: Overleaf toolkit, docker-compose.yml eller annet (stryk det som ikke passer)
• Versjon: 3.5.x (toolkit: $ cat config/version)
• Utdata fra migreringsskriptet (som skal ligge i containeren under /overleaf/services/web)
• Migrated Projects: (ifølge utdataene fra migreringsskriptet)
• Total Projects: (ifølge utdataene fra migreringsskriptet)
• Remaining Projects: (ifølge utdataene fra migreringsskriptet)
• Varighet for migreringen:
• Utdata fra bin/doctor (når du bruker toolkit)
• Toolkit-versjon: $ git rev-parse HEAD (når du bruker Toolkit)

Vurder å legge ved loggfilene for tjenestene history-v1, project-history og track-changes i e-posten. Du finner dem i /var/log/sharelatex inne i sharelatex-containeren og kan eksportere dem slik:

$ docker cp sharelatex:/var/log/sharelatex/history-v1.log history-v1.log
$ docker cp sharelatex:/var/log/sharelatex/project-history.log project-history.log
$ docker cp sharelatex:/var/log/sharelatex/track-changes.log track-changes.log

Fjern eventuell sensitiv informasjon fra loggfilene før du legger dem ved.

​

Finne ødelagte filtrær

Migreringen kan mislykkes for prosjekter som har et feilformet filtre (for eksempel der filnavn er tomme). Du kan finne en liste over slike problemer med skriptet find_malformed_filetrees, som kontrollerer alle prosjekter i databasen:

$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/find_malformed_filetrees.js"
BAD PATH: 123456789012345678901234 rootFolder.0.1.2.3
BAD PATH: 123456789012345678901234 rootFolder.0.4.5.6
...

For å rette de ugyldige stiene bruker du skriptet fix_malformed_filetree og kjører kommandoen én gang for hver ugyldig sti:

$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.1.2.3"
$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; node scripts/fix_malformed_filetree.js 123456789012345678901234 rootFolder.0.4.5.6"
...

​

Nedgradere prosjekter fra full prosjekthistorikk til eldre historikk

Hvis et prosjekt er migrert til full prosjekthistorikk, men du vil gå tilbake til den eldre historikken, bruker du skriptet downgrade_project slik:

$ bin/docker-compose exec sharelatex /bin/bash -c "cd /overleaf/services/web; PROJECT_ID=YOUR