(Migration v5.0.1) Récupération des versions de documents

Si vous n’avez jamais exécuté Server Pro version 5.0.1 ni Community Edition version 5.0.1, ou si vous avez démarré une toute nouvelle instance en 5.0.1, vous n’avez pas besoin d’exécuter ce processus de récupération.

• (2024-04-22 13:40 BST) : ajout de l’étape « Empêcher l’arrivée de nouvelles mises à jour dans le système et vider toutes les modifications vers MongoDB ».
• (2024-04-23 11:45 BST) : prise en compte des vidages défaillants en 5.0.1 et omission des vidages si la 5.0.2 a été démarrée.

La durée de la récupération dépend du nombre et de la taille des projets de votre instance, ainsi que du backend de stockage utilisé par le magasin d’historique pour les chunks (tel que défini dans OVERLEAF_HISTORY_CHUNKS_BUCKET).

Le processus de récupération retarde le démarrage de l’application dans le conteneur Server Pro. Le site apparaîtra hors ligne pendant ce temps. Nous ne prenons en charge l’exécution de la récupération que depuis une seule instance du conteneur Server Pro ; tous les autres workers de mise à l’échelle horizontale doivent être arrêtés.

Vous pouvez interrompre puis reprendre le processus de récupération si nécessaire.

D’après nos tests de performance, le processus de récupération peut traiter environ 10 000 petits projets par minute sur du matériel moderne (CPU cadencé à 3 GHz et stockage NVMe local). Par exemple, pour une instance comptant 100 000 projets, prévoyez une fenêtre de maintenance permettant au moins 10+2 minutes d’interruption. Utilisez la requête suivante pour estimer le nombre de projets de votre instance :

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

Veuillez lire intégralement les étapes de récupération suivantes avant de commencer. Les clients Server Pro peuvent contacter [e-mail] pour toute question.

​

Processus de récupération

1. Télécharger les images de la version

   Téléchargez les images de la version 5.0.3.

2. Identifier quelques projets

   Identifiez, par leur identifiant, quelques projets dont l’historique est manquant ; idéalement, vous devriez avoir l’autorisation de modifier l’un d’entre eux.

3. Planifier la maintenance

   Planifiez une fenêtre de maintenance pour l’interruption de service.

4. Arrêter tous les workers sauf un

   Arrêtez tous les workers sauf un si vous utilisez une configuration de mise à l’échelle horizontale.

5. Bloquer les nouvelles mises à jour et vider toutes les modifications vers MongoDB

   Empêchez l’arrivée de nouvelles mises à jour dans le système et videz toutes les modifications vers MongoDB :

   1. Fermez l’éditeur et déconnectez manuellement tous les utilisateurs via le panneau d’administration à l’adresse https://my-server-pro.example.com/admin#open-close-editor, dans l’onglet « Open/Close Editor ».

   2. Arrêtez le service Websocket/real-time.

      $ docker exec sharelatex sv stop real-time-overleaf
      

   3. Attendez que le service real-time se termine, ce qui est indiqué par 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. Arrêtez le conteneur git-bridge s’il est activé.

      $ docker stop git-bridge
      

   5. Si vous n’avez jamais exécuté la 5.0.2 : lancez un vidage manuel des mises à jour de documents et attendez qu’il se termine avec succès.

      Vous pouvez relancer la commande en cas d’erreur. Si vous constatez un failureCount non nul lors d’exécutions successives, arrêtez la migration (rétablissez les services avec docker restart git-bridge sharelatex) et contactez le support.

      $ 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. Si vous n’avez jamais exécuté la 5.0.2 : assurez-vous que toutes les modifications ont bien été vidées de Redis.

      Si redis-cli affiche quoi que ce soit, arrêtez la migration (rétablissez les services avec docker restart git-bridge sharelatex) et contactez le support.

      $ 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. Essayez de vider les modifications d’historique en attente.

      Ce vidage se fera au mieux, car certains projets ont un historique endommagé à cause de la migration défectueuse de la base de données. Tout échec sera corrigé par une resynchronisation de l’historique à la fin du processus de récupération.

      $ docker exec sharelatex bash -c 'source /etc/container_environment.sh && source /
          
      
6. Effectuer une sauvegarde

   Envisagez d’effectuer une sauvegarde cohérente de l’instance.

7. Mettre à niveau

   Mettez à niveau vers la version 5.0.3.

8. Récupération automatique

   Le processus de récupération s’exécute automatiquement au démarrage du conteneur.

9. Suivre la progression

   Vous pouvez suivre la progression du script en affichant en continu le fichier journal /var/lib/overleaf/data/history/doc-version-recovery.log. Il indique le nombre total de projets au démarrage, puis un résumé tous les 1000 projets traités.

   $ docker exec sharelatex tail --retry --follow /var/lib/overleaf/data/history/doc-vers
   
10. Attendre la fin du processus de récupération

    Attendez la fin du processus de récupération, soit en suivant le fichier journal ci-dessus jusqu’à l’apparition d’une ligne Done., soit en attendant que Finished recovery of doc versions. s’affiche sur la sortie standard du conteneur Server Pro.

11. Valider le processus de récupération

    Validez le processus de récupération en ouvrant le panneau d’historique de quelques projets dont l’historique était auparavant manquant.

    1. Accélérez la resynchronisation des projets à tester (ils seront traités tôt ou tard, mais nous ne voulons pas attendre leur tour).

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

       (Répétez l’opération pour chacun des identifiants de projet à tester, en remplaçant 000000000000000000000000 par un identifiant de projet à la fois.)

    2. Ouvrez l’éditeur des projets : https://my-server-pro.example.com/project/000000000000000000000000

    3. Ouvrez le panneau « History » du projet et vérifiez que le contenu le plus récent apparaît.

    4. Facultatif : refermez le panneau « History ». Apportez une modification au code, par exemple en ajoutant un commentaire dans l’en-tête.

    5. Facultatif : lancez une recompilation pour déclencher le vidage de la modification locale. Rouvrez le panneau « History » et vérifiez que la modification apparaît. Une fois terminé, annulez la modification.

12. En cas de mise à l'échelle horizontale...

    Redémarrez les autres workers.

13. Laisser l'instance en fonctionnement

    Laissez en fonctionnement l’instance qui a exécuté le processus de récupération. Elle resynchronisera l’historique de tous les projets en arrière-plan, un projet à la fois. Cela entraînera une charge de base légèrement plus élevée. (Vous pouvez redémarrer l’instance, mais les resynchronisations devront alors recommencer depuis le début.)

14. Prévenez-nous lorsque vous avez terminé

    Clients Server Pro : veuillez informer l’équipe de support lorsque vous avez terminé le processus de récupération.