(v3.5.13-migrering) Migrering av fullständig projekthistorik

​

Migrering av fullständig projekthistorik

Version 3.5.x av Community Edition innehåller funktionen Full Project History som redan finns i vårt SaaS-erbjudande, overleaf.com

När du har uppgraderat din instans till Overleaf CE 3.5.13 kommer alla nya projekt att använda Full Project History som standard. Befintliga projekt fortsätter att använda det äldre historiksystemet tills de migreras.

Om du uppgraderar till 3.5.13 och sedan bestämmer dig för att nedgradera till en tidigare version bör du återställa från en fullständig systemsäkerhetskopia. Historiken för projekt som skapats i 3.5.13 är inte kompatibel med tidigare versioner av Overleaf CE.

Den nya Full Project History medför flera förbättringar för användarna:

• Den spårar ändringar i binärfiler, vilket inte stöds i det äldre systemet.
• Det finns stöd för märkta versioner.
• Systemet är generellt mer robust, och risken för dataförlust är mindre.

Se dokumentationen för Full Project History för mer information om fullständig projekthistorik.

​

Migrera befintliga projekt

1. Skapa en säkerhetskopia

   Skapa en fullständig säkerhetskopia av din instans med en konsekvent ögonblicksbild av katalogerna mongo, redis och sharelatex.

2. Uppdatera

   Uppdatera versionen av avbildningen sharelatex/sharelatex till 3.5.13.

   Toolkit: Använd skriptet $ bin/upgrade för att uppgradera Toolkit till den senaste versionen och ändra config/version till 3.5.13.

3. Starta instansen

   Helst vill du hindra användare från att komma åt instansen medan migreringen pågår, för att undvika dataförlust om du skulle behöva återställa säkerhetskopian. Se Offlinemigrering för mer information om hur du gör detta.

4. Vänta tills alla tjänster är igång

   Vänta tills alla tjänster är igång (se kommandot nedan)

   $ bin/docker-compose exec sharelatex /bin/bash -c "curl http://localhost:3000/status"
   web sharelatex is alive (api)%
   
5. Kö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 rensar delvis migrerade projekthistorikdata i det nya systemet, vilket gör det möjligt att göra om migreringen för enskilda projekt som misslyckades vid tidigare försök;

   --fix-invalid-characters ersätter icke utskrivbara tecken som inte stöds av det nya historiksystemet;

   --convert-large-docs-to-file konverterar dokument som överstiger gränsen på 2 MB för redigerbar storlek till en icke-redigerbar fil)

   Utdata bör se ut så här:

   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.
   

   Om migreringen lyckas får du slutkoden 0, och de sista raderna visar att inga fel uppstod:

   Projects failed:  0
   Done.
   

   Du kan öppna åtkomsten för användarna igen (se nästa steg). Om det uppstod fel, se felsökningsavsnittet nedan. Du kan fortfarande öppna webbplatsen igen om problemen inte åtgärdas direkt, och de projekt som inte migrerats stannar kvar i det äldre historiksystemet.

6. Öppna webbplatsen igen

   Om du valde att utföra en offlinemigrering måste du öppna webbplatsen igen. Om du fortfarande är inloggad behöver du:

   1. Klicka på knappen Admin och välja Manage Site
   2. Klicka på fliken Open/Close Editor
   3. Klicka på knappen Reopen Editor

   Om du har stängt webbläsaren måste du starta om webbplatsen med $ bin/up.

​

Offlinemigrering

För att hindra användare från att logga in medan historikmigreringsskriptet körs följer du dessa steg:

• Logga in på din Overleaf-instans med ett administratörskonto
• Klicka på knappen Admin och välj Manage Site
• Klicka på fliken Open/Close Editor
• Klicka på knappen Close Editor
• Klicka på knappen Disconnect all users

När detta är gjort omdirigeras eventuella inloggade användare till underhållssidan, och nya användare som besöker inloggningssidan ser underhållssidan och kan inte logga in.

​

Onlinemigrering

Det går att köra migreringsskripten medan applikationen fortfarande körs. Det finns några saker att tänka på:

• Migreringsprocessen är CPU-intensiv, så du bör övervaka resursanvändningen medan skriptet körs.
• Med ett högt värde för --concurrency kan händelseloopen i vissa tjänster (särskilt track-changes) blockeras i viss mån, vilket leder till en försämrad användarupplevelse. Vi rekommenderar att du börjar med standardvärdet --concurrency=1.
• Du kan stoppa skriptet när som helst. Om du startar det igen återupptas migreringen där du slutade. Det är användbart om du föredrar att köra migreringen under mindre belastade tider (t.ex. på natten).

Vår rekommendation är att stänga webbplatsen och köra migreringen offline under ett underhållsfönster om antalet projekt är färre än 1000 (db.projects.count()). Om antalet projekt är stort kan du köra skriptet och övervaka förloppet, och sedan bestämma om du ska fortsätta köra det online eller offline utifrån ditt specifika fall.

​

Rensa äldre historikdata

Ett skript för att rensa äldre historikdata lades till i Server Pro 3.5.6, 4.0.6 och 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 köras när alla projekt har migrerats. Det kan också användas för att frigöra utrymme under en onlinemigrering.

I Server Pro före version 3.5.13 tar skriptet bort innehållet i samlingarna docHistory och docHistoryIndex. MongoDB frigör inte diskutrymme när du tar bort dokument, utan återanvänder i stället utrymmet för framtida dokument i samma samling. Ingenting kommer att skriva till dessa samlingar igen efter historikmigreringen, så diskutrymmet förblir oanvänt.

Om du vill göra diskutrymmet tillgängligt igen kan du uppgradera till Server Pro 3.5.13 (om du fortfarande använder 3.x) eller Server Pro 4.2.5 (om du använder 4.x) och köra rensningsskriptet igen.

Rensningsskriptet i de senaste patchversionerna av Server Pro 3.5.x och den senaste 4.x.x tar bort samlingarna som sista steg.

Det är säkert att köra rensningsskriptet igen.

​

Felsökning

Vi kommer att lägga till felsökningsråd här. Observera att även om vi normalt endast erbjuder support till Server Pro-kunder kommer vi, med tanke på denna migrerings natur, också att göra vårt bästa för att hjälpa CE-kunder som upplever problem som är specifika för migreringen av fullständig projekthistorik.

Om migreringsskriptet för fullständig projekthistorik misslyckas (dvs. avslutas med ett fel eller skriver ut ett antal misslyckade projekt som inte är noll) ber vi dig skicka följande uppgifter till vårt supportteam via e-post till [e-mail], med följande:

Ämne: Full project history migration problem

• Instanstyp: CE eller Server Pro (stryk det som inte gäller)
• Installationstyp: Overleaf toolkit eller docker-compose.yml eller annat (stryk det som inte gäller)
• Version: 3.5.x (toolkit: $ cat config/version)
• Utdata från migreringsskriptet (som bör finnas i containern under /overleaf/services/web)
• Migrated Projects: (enligt utdata från migreringsskriptet)
• Total Projects: (enligt utdata från migreringsskriptet)
• Remaining Projects: (enligt utdata från migreringsskriptet)
• Migreringens varaktighet:
• Utdata från bin/doctor (om du använder toolkit)
• Toolkit-version: $ git rev-parse HEAD (om du använder Toolkit)

Överväg att bifoga loggfilerna för tjänsterna history-v1, project-history och track-changes i e-postmeddelandet. Du hittar dem under /var/log/sharelatex i containern sharelatex och kan exportera dem så här:

$ 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

Ta bort all känslig information från loggfilerna innan du bifogar dem.

​

Hitta trasiga filträd

Migreringen kan misslyckas för projekt som har ett felformat filträd (till exempel där filnamn är tomma). Du kan få en lista över dessa problem med skriptet find_malformed_filetrees, som kontrollerar alla projekt 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
...

För att åtgärda de ogiltiga sökvägarna använder du skriptet fix_malformed_filetree och kör kommandot en gång för varje felaktig sökväg:

$ 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"
...

​

Nedgradera projekt från fullständig projekthistorik till äldre historik

Om ett projekt har migrerats till fullständig projekthistorik men du vill gå tillbaka till den äldre historiken använder du skriptet downgrade_project så här:

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