Skip to main content
Toute nouvelle version de Server CE/Server Pro signale dans ses notes de version tout changement concernant la version de MongoDB prise en charge.

Dois-je mettre à jour MongoDB ?

Vous ne devriez envisager de mettre à jour votre version de MongoDB que si vous prévoyez de mettre à niveau votre instance de Server CE/Server Pro. Si vous utilisez une version de MongoDB plus récente que celle recommandée pour votre version actuelle (ou cible), aucune modification n’est nécessaire.
Vous ne devez jamais rétrograder votre version de MongoDB.
Si vous rencontrez un problème spécifique qui pourrait selon vous être lié à votre version actuelle de MongoDB, n’hésitez pas à ouvrir un ticket si vous utilisez Server CE, ou à contacter le support Overleaf si vous utilisez Server Pro.

Vérifier votre version de MongoDB

L’ouverture du shell mongo devrait immédiatement afficher la version actuelle. Utilisateurs de l’Overleaf Toolkit :
Utilisateurs de Docker Compose :

Processus de mise à jour

La mise à jour de la version de MongoDB lors d’une mise à niveau de votre instance Server CE/Server Pro se déroule comme suit :
  1. Choisissez la version de Server CE/Server Pro vers laquelle vous prévoyez de mettre à niveau.
  2. Identifiez la version de MongoDB recommandée par cette version précise d’Overleaf Server CE/Server Pro.
  3. Suivez les instructions pour mettre à niveau MongoDB vers la version cible.
  4. Mettez à niveau la version de l’image Server CE/Server Pro et redémarrez l’instance.
Nous recommandons de toujours mettre à niveau Server CE/Server Pro vers la dernière version disponible, car sa prise en charge est toujours garantie (utilisateurs de Server Pro uniquement).
Lors d’une mise à niveau de Server CE/Pro, nous recommandons de passer à la dernière version de la version majeure déployée avant de passer à la dernière version de la version majeure suivante. Si votre déploiement a plus d’une version majeure de retard sur la dernière, vous devrez effectuer une mise à niveau en plusieurs étapes.Par exemple, si vous utilisez la 3.5.10, vous devrez passer à la 3.5.13 -> effectuer la migration vers l’historique complet des projets -> 4.2.9 -> 5.5.4.Vous ne devez jamais sauter de versions majeures (3.5.10 -> 5.5.4). Si vous utilisez le Toolkit et que vous avez plus d’une version majeure de retard, vous ne devez pas utiliser le script bin/upgrade, car vous devrez effectuer une mise à niveau manuelle en plusieurs étapes.
Il est important d’effectuer une sauvegarde cohérente avant chaque mise à niveau de version majeure afin de pouvoir revenir en arrière si nécessaire.

Informations sur les versions prises en charge

Si vous décidez de passer à une version antérieure, ce tableau indique la version de MongoDB recommandée pour les versions antérieures de Server CE/Server Pro, mais vous ne devez jamais rétrograder votre version de MongoDB.
Server CE/Server ProVersion de MongoDBVersion minimale de compatibilité des fonctionnalitésVersion maximale prise en charge par le pilote Node.js
2.0.x3.4--
2.1.x à 2.4.x3.6--
>=2.5.04.0--
>=3.1.04.2--
>=3.2.04.4--
>=4.2.05.0--
>=5.1.06.0--
>=5.3.16.05.08.0
>=5.5.06.06.08.0
6.0.08.08.08.0
La version minimale de compatibilité des fonctionnalités ci-dessus correspond à la version de MongoDB recommandée pour la version d’Overleaf indiquée. Si vous prévoyez d’utiliser une version plus récente, MongoDB aura ses propres exigences minimales.
Vous pouvez consulter le tableau de compatibilité indiquant les versions du pilote Node.js de MongoDB prises en charge avec MongoDB ici. Vous pouvez consulter le statut de fin de vie de chaque version de MongoDB ici.

Mettre à niveau MongoDB

MongoDB exige des mises à niveau étape par étape. Cela signifie que vous ne pouvez pas passer directement, par exemple, de 4.0 à 5.0. Vous devez d’abord passer de 4.2 à 4.4, puis à 5.0.
MongoDB utilise des nombres pairs pour ses versions stables.

Instructions de mise à jour lorsque MongoDB s’exécute en dehors de Docker

Voici les liens vers les instructions de mise à jour de mongodb.com pour la mise à niveau de MongoDB.
Les instructions à partir de 5.0 renvoient à une installation en replica set plutôt qu’en mode autonome. Comme Server Pro/CE 4.0.1+ utilise des transactions, MongoDB doit être exécuté en tant que replica set.
La documentation de MongoDB 3.2 à 4.2 est désormais disponible via https://www.mongodb.com/docs/legacy/
Instructions de base Dans la plupart des cas, la mise à jour nécessite de définir un indicateur de compatibilité avant de mettre réellement à jour la version de mongo. Les étapes sont les suivantes :
  1. Définissez l’indicateur de compatibilité comme décrit dans les notes de version de MongoDB (voir les exemples ci-dessous).
  2. Mettez ensuite à jour l’image mongo :
    1. Utilisateurs du Toolkit : mettez à jour MONGO_VERSION, par exemple MONGO_VERSION=6.0
    2. Utilisateurs de Docker Compose : mettez à jour la version du tag de l’image mongo,
      par exemple services -> mongo -> image: mongo:6.0 ;
Exemple : mise à niveau de MongoDB de 5.0 vers 6.0 Commençons par vérifier que nous utilisons MongoDB 6.0 : Utilisateurs de l’Overleaf Toolkit :
Utilisateurs de Docker Compose :
D’après les instructions de mise à niveau, la seule exigence est que featureCompatibilityVersion soit défini sur 5.0. Pour cela, nous ouvrons un shell MongoDB et exécutons la commande indiquée : Utilisateurs de l’Overleaf Toolkit :
Les utilisateurs de Docker Compose peuvent exécuter docker compose exec mongo mongosh pour obtenir un shell et exécuter les mêmes commandes que les utilisateurs du Toolkit.
Utilisateurs de l’Overleaf Toolkit : Nous arrêtons ensuite les instances Server CE/Server Pro et MongoDB à l’aide de la commande bin/stop, définissons MONGO_VERSION=6.0 dans config/overleaf.rc, puis redémarrons le service mongo avec bin/up mongo) afin de vérifier que la mise à jour s’est bien déroulée. Enfin, nous mettons à jour la version de l’image Server CE/Server Pro vers notre version cible et recréons tous les services à l’aide de la commande bin/up -d. Utilisateurs de Docker Compose : Nous arrêtons ensuite les instances Server CE/Server Pro et MongoDB à l’aide de la commande docker compose stop, modifions le fichier docker-compose.yml pour utiliser image: mongo:6.0, puis redémarrons le service mongo avec la commande docker compose up mongo afin de vérifier que la mise à jour s’est bien déroulée. Enfin, nous mettons à jour la version de l’image Server CE/Server Pro vers notre version cible et recréons tous les services à l’aide de la commande docker compose up. Commencez par vérifier que vous utilisez MongoDB 6.0 à l’aide des commandes mongod --version ci-dessus. D’après les instructions de mise à niveau, la seule exigence est que featureCompatibilityVersion soit défini sur 6.0. Pour cela, nous ouvrons un shell MongoDB et exécutons la commande db.adminCommand({ setFeatureCompatibilityVersion: "6.0" }). Utilisateurs de l’Overleaf Toolkit :
Nous arrêtons ensuite les instances Server CE/Server Pro et MongoDB à l’aide de la commande bin/stop, définissons MONGO_VERSION=7.0 dans config/overleaf.rc, puis redémarrons le service mongo avec bin/up mongo) afin de vérifier que la mise à jour s’est bien déroulée. Enfin, nous mettons à jour la version de l’image Server CE/Server Pro vers notre version cible et recréons tous les services à l’aide de la commande bin/up -d. Commencez par vérifier que vous utilisez MongoDB 7.0 à l’aide des commandes mongod --version ci-dessus. D’après les instructions de mise à niveau, la seule exigence est que featureCompatibilityVersion soit défini sur 7.0. Pour cela, nous ouvrons un shell MongoDB et exécutons la commande db.adminCommand({ setFeatureCompatibilityVersion: "7.0", confirm: true }). Notez que cela nécessite désormais un paramètre supplémentaire confirm: true.
Nous arrêtons ensuite les instances Server CE/Server Pro et MongoDB à l’aide de la commande bin/stop, définissons MONGO_VERSION=8.0 dans config/overleaf.rc, puis redémarrons le service mongo avec bin/up mongo) afin de vérifier que la mise à jour s’est bien déroulée. Enfin, nous mettons à jour la version de l’image Server CE/Server Pro vers notre version cible et recréons tous les services à l’aide de la commande bin/up -d.

Commandes équivalentes pour les utilisateurs de docker compose

Pour les utilisateurs de docker compose, les commandes équivalentes sont :
  • docker compose exec mongo mongod --version pour afficher la version de mongo
  • docker compose exec mongo mongosh pour démarrer un shell mongo pour les commandes d’administration
  • La commande docker compose stop pour arrêter le serveur
  • Modifiez le fichier docker-compose.yml pour utiliser image: mongo:6.0 afin de mettre à niveau la version de mongo
  • docker compose up mongo pour redémarrer le service mongo et vérifier que la mise à jour s’est bien déroulée
  • Modifiez le fichier docker-compose.yml pour utiliser image: sharelatex:VERSION afin de mettre à niveau la version de l’image
  • docker compose up pour recréer tous les services.

Créer un rôle personnalisé

Dans la version 5.5.1, nous avons introduit une vérification au démarrage de la version de compatibilité des fonctionnalités de MongoDB. Si votre base de données MongoDB utilise l’authentification (par exemple l’authentification basique), il se peut que le conteneur sharelatex ne démarre pas et affiche une erreur de permission « not authorized on admin to execute command ». Pour résoudre ce problème, vous pouvez soit créer un nouveau rôle dans MongoDB et l’attribuer au compte utilisateur utilisé pour accéder à la base de données en suivant les instructions ci-dessous, soit définir ALLOW_MONGO_ADMIN_CHECK_FAILURES=true pour que l’échec de la vérification n’empêche pas le démarrage du déploiement.
Ce nouveau rôle accorde uniquement la permission de lire les paramètres du serveur MongoDB à l’échelle du cluster et peut être réutilisé à des fins de supervision.
Dernière modification le 5 octobre 2026