(Migrazione v5.0.1) Recupero delle versioni dei documenti

Se non hai mai eseguito Server Pro versione 5.0.1 o Community Edition versione 5.0.1, oppure hai avviato un’istanza completamente nuova con la 5.0.1, non è necessario eseguire questo processo di recupero.

• (2024-04-22 13:40 BST): aggiunto il passaggio “Bloccare l’ingresso di nuovi aggiornamenti nel sistema e scaricare tutte le modifiche in MongoDB”.
• (2024-04-23 11:45 BST): gestiti i flush non riusciti nella 5.0.1 e saltati i flush quando era stata avviata la 5.0.2.

La durata del recupero dipende dal numero e dalle dimensioni dei progetti nella tua istanza e dal backend di archiviazione usato dallo storico per i chunk (come definito in OVERLEAF_HISTORY_CHUNKS_BUCKET).

Il processo di recupero ritarda l’avvio dell’applicazione all’interno del container Server Pro. Durante questo periodo il sito risulterà offline. Supportiamo l’esecuzione del recupero solo da una singola istanza del container Server Pro; tutti gli altri worker di scalabilità orizzontale devono essere offline.

Se necessario, puoi interrompere e riprendere il processo di recupero.

In base ai nostri test sulle prestazioni, il processo di recupero può elaborare circa 10.000 piccoli progetti al minuto su hardware moderno (CPU a 3 GHz e storage NVMe locale). Ad esempio, per un’istanza con 100.000 progetti, pianifica una finestra di manutenzione che consenta almeno 10+2 minuti di inattività. Usa la seguente query per stimare il numero di progetti nella tua istanza:

$ docker exec mongo mongosh sharelatex --quiet --eval 'db.projects.estimatedDocumentCount() + db.deletedProjects.estimatedDocumentCount()'

Leggi interamente i seguenti passaggi di recupero prima di iniziare. I clienti Server Pro sono invitati a contattare [e-mail] per qualsiasi domanda.

​

Processo di recupero

1. Scarica le immagini della release

   Scarica le immagini della release 5.0.3.

2. Individua alcuni progetti

   Individua tramite id alcuni progetti a cui manca la cronologia; idealmente dovresti avere il permesso di apportare una modifica ad almeno uno di essi.

3. Pianifica la manutenzione

   Pianifica una finestra di manutenzione per il periodo di inattività.

4. Arresta tutti i worker tranne uno

   Se usi una configurazione con scalabilità orizzontale, arresta tutti i worker tranne uno.

5. Blocca i nuovi aggiornamenti e scarica tutte le modifiche in MongoDB

   Blocca l’ingresso di nuovi aggiornamenti nel sistema e scarica tutte le modifiche in MongoDB:

   1. Chiudi l’editor e disconnetti manualmente tutti gli utenti tramite il pannello di amministrazione su https://my-server-pro.example.com/admin#open-close-editor, nella scheda “Open/Close Editor”.

   2. Arresta il servizio Websocket/real-time.

      $ docker exec sharelatex sv stop real-time-overleaf
      

   3. Attendi che il servizio real-time termini, come indicato da down:.

      $ docker exec sharelatex sv status real-time-overleaf
      run: real-time-sharelatex: (pid 394) 50s, want down, got TERM
      # wait a little longer...
      
      $ docker exec sharelatex sv status real-time-overleaf
      down: real-time-sharelatex: 7s, normally up
      

   4. Arresta il container git-bridge, se abilitato.

      $ docker stop git-bridge
      

   5. Se non hai mai eseguito la 5.0.2: avvia un flush manuale degli aggiornamenti dei documenti e attendi che termini correttamente.

      In caso di errore puoi ripetere il comando. Se nelle esecuzioni successive vedi un failureCount diverso da zero, interrompi la migrazione (ripristina i servizi con docker restart git-bridge sharelatex) e contatta il supporto.

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /etc/overleaf/env.sh && cd services/document-updater && LOG_LEVEL=info node scripts/flush_all.js'
          ...
          {"name":"default","hostname":"...","pid":324,"level":30,"successCount":...,"failureCount":0,"msg":"finished flushing all projects","time":"...","v":0}
          Done flushing all projects
          
      

   6. Se non hai mai eseguito la 5.0.2: assicurati che tutte le modifiche siano state scaricate da Redis.

      Se redis-cli produce un qualsiasi output, interrompi la migrazione (ripristina i servizi con docker restart git-bridge sharelatex) e contatta il supporto.

      $ docker exec redis redis-cli --scan --pattern 'DocVersion:*'
          # no output from redis-cli indicates success, check exit code of redis-cli next, it should be zero
          $ echo $?
          0
          
      

   7. Prova a scaricare tutte le modifiche alla cronologia in sospeso.

      Questo flush sarà eseguito al meglio delle possibilità, poiché alcuni progetti hanno cronologie danneggiate a causa della migrazione errata del database. Eventuali errori verranno risolti con una risincronizzazione della cronologia al termine del processo di recupero.

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /
          
      
6. Esegui un backup

   Valuta di eseguire un backup coerente dell’istanza.

7. Aggiorna

   Aggiorna alla versione 5.0.3.

8. Recupero automatico

   Il processo di recupero viene eseguito automaticamente all’avvio del container.

9. Segui l'avanzamento

   Puoi seguire l’avanzamento dello script osservando la coda del file di log /var/lib/overleaf/data/history/doc-version-recovery.log. All’inizio verrà stampato il numero totale di progetti e, ogni 1000 progetti elaborati, un riepilogo.

   $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
   
10. Attendi il completamento del processo di recupero

    Attendi il completamento del processo di recupero seguendo il file di log indicato sopra finché non viene stampata una riga Done., oppure attendendo che Finished recovery of doc versions. venga stampato sullo standard output del container Server Pro.

11. Verifica il processo di recupero

    Verifica il processo di recupero aprendo il pannello della cronologia per alcuni dei progetti a cui in precedenza mancava la cronologia.

    1. Accelera la risincronizzazione dei progetti da testare (verranno comunque elaborati prima o poi, ma non vogliamo attendere il loro turno).

       $ docker exec sharelatex curl -X POST --silent "http://127.0.0.1:3054/project/000000000000000000000000/resync?force=true"
           
       

       (Ripeti per ciascuno degli id di progetto da testare, sostituendo 000000000000000000000000 con un id di progetto alla volta.)

    2. Apri l’editor per i progetti https://my-server-pro.example.com/project/000000000000000000000000

    3. Apri il pannello “History” del progetto e verifica il contenuto più recente.

    4. Facoltativo: chiudi di nuovo il pannello “History”. Apporta una modifica al codice, ad esempio aggiungendo un commento all’intestazione.

    5. Facoltativo: avvia una ricompilazione per attivare il flush della modifica locale. Apri di nuovo il pannello “History” e verifica la modifica. Al termine, annulla la modifica.

12. Per la scalabilità orizzontale...

    Riavvia gli altri worker.

13. Mantieni l'istanza in esecuzione

    Mantieni in esecuzione l’istanza che ha eseguito il processo di recupero. Risincronizzerà in background la cronologia di tutti i progetti con una concorrenza pari a 1. Ciò comporterà un carico di base leggermente più elevato. (Puoi riavviare l’istanza, ma dovrà ricominciare da capo le risincronizzazioni.)

14. Facci sapere quando hai finito

    Clienti Server Pro: comunicate al team di supporto quando avete completato il processo di recupero.