Migrazione della cronologia completa dei progetti
La release3.5.x della Community Edition include la funzionalità Full Project History, già disponibile nella nostra offerta SaaS, overleaf.com
Dopo aver aggiornato la tua istanza a Overleaf CE 3.5.13, tutti i nuovi progetti utilizzeranno la Full Project History per impostazione predefinita. I progetti esistenti continueranno a utilizzare il sistema di cronologia legacy finché non verranno migrati.
Se effettui l’aggiornamento alla
3.5.13 e decidi di tornare a una versione precedente, dovrai eseguire il ripristino da un backup completo del sistema. La cronologia dei progetti creati nella 3.5.13 non è compatibile con le versioni precedenti di Overleaf CE.- Traccia le modifiche nei file binari, cosa non supportata dal sistema legacy.
- Supporta le versioni etichettate.
- Il sistema è in generale più robusto e il rischio di perdita di dati è minore.
Migrare i progetti esistenti
1
Creare un backup
Crea un backup completo della tua istanza con uno snapshot coerente delle directory mongo, redis e sharelatex.
2
Aggiornare
Aggiorna la versione dell’immagine sharelatex/sharelatex alla 3.5.13.Toolkit: usa lo script
$ bin/upgrade per aggiornare il toolkit all’ultima versione e modifica config/version impostandolo su 3.5.13.3
Avviare l'istanza
Idealmente, dovresti impedire agli utenti di accedere alla tua istanza durante la migrazione, per evitare perdite di dati nel caso in cui tu debba ripristinare il backup. Consulta Migrazione offline per ulteriori informazioni su come farlo.
4
Attendere che tutti i servizi siano attivi e funzionanti
Attendi che tutti i servizi siano attivi e funzionanti (vedi il comando seguente)
5
Eseguire lo script di migrazione
--force-clean elimina i dati della cronologia dei progetti parzialmente migrati nel nuovo sistema; ciò consente di ritentare la migrazione dei singoli progetti non riuscita nei tentativi precedenti;--fix-invalid-characters sostituisce i caratteri non stampabili non supportati dal nuovo sistema di cronologia;--convert-large-docs-to-file converte i documenti che superano la soglia di dimensione modificabile di 2MB in file non modificabili)L’output dovrebbe essere simile a questo:0 e le ultime righe indicheranno che non ci sono stati errori:6
Riaprire il sito
Se hai scelto di eseguire una migrazione offline, dovrai riaprire il sito. Se hai ancora effettuato l’accesso, dovrai:
- Fare clic sul pulsante Admin e scegliere Manage Site
- Fare clic sulla scheda Open/Close Editor
- Fare clic sul pulsante Reopen Editor
$ bin/up.Migrazione offline
Per impedire agli utenti di accedere mentre lo script di migrazione della cronologia è in esecuzione, segui questi passaggi:- Accedi alla tua istanza Overleaf con un account amministratore
- Fai clic sul pulsante Admin e scegli Manage Site
- Fai clic sulla scheda Open/Close Editor
- Fai clic sul pulsante Close Editor
- Fai clic sul pulsante Disconnect all users
Migrazione online
È possibile eseguire gli script di migrazione mentre l’applicazione è ancora in esecuzione. Ci sono alcune considerazioni da tenere presenti:- Il processo di migrazione è intensivo per la CPU: dovresti monitorare l’utilizzo delle risorse mentre lo script è in esecuzione.
- Con un valore di
--concurrencyelevato, l’event loop di alcuni servizi (in particolaretrack-changes) potrebbe subire dei blocchi, con un conseguente peggioramento dell’esperienza utente. Consigliamo di iniziare con il valore predefinito--concurrency=1. - Puoi interrompere lo script in qualsiasi momento. Riavviandolo, la migrazione riprenderà dal punto in cui l’avevi lasciata. Ciò è utile se preferisci eseguire la migrazione nelle ore meno trafficate (ad es. di notte).
db.projects.count()). Se il numero di progetti è elevato, puoi eseguire lo script e monitorarne l’avanzamento, quindi decidere se continuare l’esecuzione online o offline in base al tuo caso specifico.
Ripulire i dati della cronologia legacy
Uno script per ripulire i dati della cronologia legacy è stato aggiunto in Server Pro3.5.6, 4.0.6 e 4.1.0.
In Server Pro prima della versione 3.5.13, lo script elimina il contenuto delle collezioni
docHistory e docHistoryIndex. MongoDB non rilascia lo spazio su disco dopo l’eliminazione dei documenti, ma lo riutilizza per i futuri documenti della stessa collezione. Dopo la migrazione della cronologia nulla scriverà più in queste collezioni, quindi lo spazio su disco resterà inutilizzato.Se vuoi rendere nuovamente disponibile lo spazio su disco, puoi aggiornare a Server Pro 3.5.13 (se usi ancora la release 3.x) o a Server Pro 4.2.5 (se usi la release 4.x) ed eseguire di nuovo lo script di pulizia.Lo script di pulizia incluso nelle ultime patch release di Server Pro 3.5.x e nell’ultima 4.x.x elimina le collezioni come passaggio finale.Puoi eseguire di nuovo lo script di pulizia in tutta sicurezza.Risoluzione dei problemi
Aggiungeremo qui dei consigli per la risoluzione dei problemi. Tieni presente che, sebbene normalmente offriamo supporto solo ai clienti Server Pro, data la natura di questa migrazione faremo del nostro meglio per supportare anche i clienti CE che riscontrano problemi specifici della migrazione della cronologia completa dei progetti. Se lo script di migrazione della cronologia completa dei progetti non va a buon fine (ovvero termina con un errore o riporta un numero di progetti non riusciti diverso da zero), invia i seguenti dettagli al nostro team di supporto via email a support+historymigration@overleaf.com, specificando: Oggetto: Full project history migration problem- Tipo di istanza: CE o Server Pro (elimina la voce non pertinente)
- Tipo di installazione: Overleaf toolkit,
docker-compose.ymlo altro (elimina le voci non pertinenti) - Versione: 3.5.x (toolkit:
$ cat config/version) - Output dello script di migrazione (che dovrebbe trovarsi nel container in
/overleaf/services/web) - Migrated Projects: (secondo l’output dello script di migrazione)
- Total Projects: (secondo l’output dello script di migrazione)
- Remaining Projects: (secondo l’output dello script di migrazione)
- Durata della migrazione:
- Output di
bin/doctor(se usi il toolkit) - Versione del Toolkit:
$ git rev-parse HEAD(se usi il Toolkit)
history-v1, project-history e track-changes. Li trovi in /var/log/sharelatex all’interno del container sharelatex e puoi esportarli in questo modo:
Individuare alberi di file danneggiati
La migrazione potrebbe non riuscire per i progetti con un albero di file malformato (ad esempio, con nomi di file vuoti). Puoi trovare un elenco di questi problemi usando lo scriptfind_malformed_filetrees, che controlla tutti i progetti nel database:
fix_malformed_filetree, eseguendo il comando una volta per ogni percorso errato:
Riportare i progetti dalla cronologia completa alla cronologia legacy
Se un progetto è stato migrato alla cronologia completa ma vuoi tornare alla cronologia legacy, usa lo scriptdowngrade_project come segue:

