> For the complete documentation index, see [llms.txt](https://overleaf-pro.ayaka.space/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://overleaf-pro.ayaka.space/on-premises/fr/maintenance/updating-mongodb.md). # Mise à jour de MongoDB {% hint style="info" %} Toute nouvelle version de Server CE/Server Pro indiquera tout changement concernant la version de MongoDB prise en charge dans ses [notes de version](https://docs.overleaf.com/on-premises/release-notes). {% endhint %} ### Dois-je mettre à jour MongoDB ? Vous devriez **uniquement** envisager de mettre à jour votre version de MongoDB 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), il n'est pas nécessaire d'effectuer des changements. {% hint style="warning" %} Vous ne devriez jamais rétrograder votre version de MongoDB. {% endhint %} Si vous rencontrez un problème spécifique que vous pensez lié à votre version actuelle de MongoDB, n'hésitez pas à [ouvrir une issue](https://github.com/overleaf/overleaf/issues) si vous êtes un utilisateur de Server CE, ou contactez le support Overleaf si vous êtes un utilisateur de Server Pro. ### Vérification de votre version de MongoDB L'ouverture du `mongo` shell devrait immédiatement afficher la version actuelle. Utilisateurs du Toolkit Overleaf : ```bash bin/docker-compose exec mongo mongod --version version de la base de données v5.0.24 Infos de compilation : { "version": "5.0.24", "gitVersion": "f034f0c51b3dffef4b8c9452d77ede9888f28f66", "openSSLVersion": "OpenSSL 1.1.1f 31 Mar 2020", "modules": [], "allocator": "tcmalloc", "environment": { "distmod": "ubuntu2004", "distarch": "x86_64", "target_arch": "x86_64" } } ``` Utilisateurs de Docker Compose : ```bash docker compose exec mongo mongod --version version de la base de données v5.0.24 Infos de compilation : { "version": "5.0.24", "gitVersion": "f034f0c51b3dffef4b8c9452d77ede9888f28f66", "openSSLVersion": "OpenSSL 1.1.1f 31 Mar 2020", "modules": [], "allocator": "tcmalloc", "environment": { "distmod": "ubuntu2004", "distarch": "x86_64", "target_arch": "x86_64" } } ``` ### Processus de mise à jour La mise à jour de la version de MongoDB lors de la mise à niveau de votre instance Server CE/Server Pro se déroule comme suit : 1. Décidez de la version de Server CE/Server Pro vers laquelle vous prévoyez de mettre à niveau. 2. Trouvez la version de MongoDB recommandée par cette version spécifique de Server CE/Server Pro d'Overleaf. 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. Notre recommandation est de toujours mettre à niveau **Server CE/Server Pro** vers la dernière version disponible, car elle est toujours garantie d'être prise en charge (utilisateurs de Server Pro uniquement). {% hint style="danger" %} 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 **prochaine** version majeure. Si votre déploiement a plus d'une version majeure de retard sur la dernière version, vous devrez effectuer une mise à niveau en plusieurs étapes. Par exemple, si vous utilisez 3.5.10, vous devrez mettre à niveau vers 3.5.13 -> effectuer la migration Full Project History -> 4.2.9 -> 5.5.4. Vous devriez **ne jamais** sauter les versions majeures (3.5.10 -> 5.5.4). Si vous utilisez le Toolkit et avez plus d'une version majeure de retard sur la dernière, vous devez **ne pas** utiliser le `bin/upgrade` script, car vous devrez effectuer une mise à niveau manuelle en plusieurs étapes. {% endhint %} {% hint style="warning" %} Il est important de s'assurer que vous effectuez une [sauvegarde cohérente](/on-premises/fr/maintenance/data-and-backups.md#performing-a-consistent-backup) **avant** à chaque mise à niveau majeure afin de pouvoir revenir en arrière si nécessaire. {% endhint %} #### Informations sur la prise en charge des versions Au cas où vous décideriez de revenir à une version antérieure, ce tableau montre la version de MongoDB recommandée pour les versions antérieures de Server CE/Server Pro, mais vous devriez **ne 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
{% hint style="danger" %} La version minimale de compatibilité des fonctionnalités ci-dessus est basée sur la version de MongoDB correspondante recommandée pour une utilisation avec la version d'Overleaf indiquée. Si vous prévoyez d'utiliser une version supérieure, MongoDB aura sa propre exigence minimale. {% endhint %} Vous pouvez consulter le tableau de compatibilité qui précise les versions prises en charge du pilote Node.js MongoDB pour une utilisation avec MongoDB [ici](https://www.mongodb.com/docs/drivers/node/current/reference/compatibility/). Vous pouvez consulter le statut de fin de vie de chaque version de MongoDB [ici](https://endoflife.date/mongodb). #### Mise à niveau de MongoDB MongoDB nécessite **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 mettre à jour `4.2` à `4.4`, puis `5.0`. {% hint style="info" %} MongoDB utilise des numéros pairs pour ses versions stables. {% endhint %} #### **Instructions de mise à jour lors de l'exécution de MongoDB hors de Docker** Voici des liens vers les instructions de mise à jour de mongodb.com lors de la mise à niveau de MongoDB. * [Notes de version MongoDB - mise à niveau de MongoDB depuis `4.2` à `4.4`](https://www.mongodb.com/docs/v4.4/release-notes/4.4-upgrade-standalone/) * [Notes de version MongoDB - mise à niveau de MongoDB depuis `4.4` à `5.0`](https://www.mongodb.com/docs/v5.0/release-notes/5.0-upgrade-replica-set/) * [Notes de version MongoDB - mise à niveau de MongoDB depuis `5.0` à `6.0`](https://www.mongodb.com/docs/v6.0/release-notes/6.0-upgrade-replica-set/) * [Notes de version MongoDB - mise à niveau de MongoDB depuis `6.0` à `7.0`](https://www.mongodb.com/docs/manual/release-notes/7.0-upgrade-replica-set/#std-label-7.0-upgrade-replica-set) * [Notes de version MongoDB - mise à niveau de MongoDB depuis `7.0` à `8.0`](https://www.mongodb.com/docs/manual/release-notes/8.0-upgrade-replica-set/#std-label-8.0-upgrade-replica-set) {% hint style="info" %} Instructions pour `5.0` et versions supérieures renvoient vers une installation en replica set, au lieu du mode autonome. Comme Server Pro/CE 4.0.1+ utilise des transactions, MongoDB doit être exécuté en tant que replica set. {% endhint %} {% hint style="warning" %} La documentation pour MongoDB 3.2 à 4.2 est désormais disponible via {% endhint %} **Instructions de base** Dans la plupart des cas, la mise à jour nécessite de configurer 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. Puis mettez à jour l'image mongo : 1. **Utilisateurs du Toolkit** Mettez à jour `MONGO_VERSION`, par ex. `MONGO_VERSION=6.0` 2. **Utilisateurs de Docker Compose** Mettez à jour la version du `mongo` tag d'image,\npar ex. `services -> mongo -> image: mongo:6.0`; **Exemple : mise à niveau de MongoDB depuis `5.0` à `6.0`** Commençons par nous assurer que MongoDB est bien en cours d'exécution `6.0`: Utilisateurs du Toolkit Overleaf : ```bash bin/docker-compose exec mongo mongod --version version de la base de données v5.0.24 ``` Utilisateurs de Docker Compose : ```bash docker compose exec mongo mongod --version version de la base de données v5.0.24 ``` Selon les [instructions de mise à niveau](https://docs.mongodb.com/manual/release-notes/3.6-upgrade-standalone/#upgrade-version-path), la seule exigence est d'avoir `featureCompatibilityVersion` défini sur `5.0`. Pour ce faire, ouvrez un shell MongoDB et exécutez la commande indiquée : Utilisateurs du Toolkit Overleaf : ```bash bin/mongo # version du shell MongoDB v5.0.24 # ... # overleaf:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "5.0" } ) # { # "ok" : 1, # ... # } overleaf:PRIMARY> exit # au revoir ``` {% hint style="info" %} 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. {% endhint %} Utilisateurs du Toolkit Overleaf : Nous arrêterons ensuite les instances Server CE/Server Pro et MongoDB à l'aide de la `bin/stop` commande, définir `MONGO_VERSION=6.0` dans `config/overleaf.rc`, puis redémarrer le `mongo` service à l'aide de `bin/up mongo`) pour vérifier que la mise à jour s'est déroulée sans problème. Enfin, nous mettrons à jour la version de l'image Server CE/Server Pro vers la version cible et recréerons tous les services à l'aide de la `bin/up -d` commande. Utilisateurs de Docker Compose : Nous arrêterons ensuite les instances Server CE/Server Pro et MongoDB à l'aide de la `docker compose stop` commande, mettez à jour [`docker-compose.yml`](https://github.com/overleaf/overleaf/blob/4b1babd4ea634ab12c54e9a9aea7db0e8a500941/docker-compose.yml) le fichier pour utiliser `image: mongo:6.0`, puis redémarrer le `mongo` service à l'aide de la `docker compose up mongo` commande pour vérifier que la mise à jour s'est déroulée sans problème. Enfin, nous mettrons à jour la version de l'image Server CE/Server Pro vers notre version cible et recréerons tous les services à l'aide de la `docker compose up` commande. **Exemple : mise à niveau de MongoDB depuis `6.0` à `7.0` (utilisateurs du toolkit)** Commencez par vous assurer que vous exécutez MongoDB `6.0` à l'aide des `commandes mongod --version` ci-dessus. Selon les [instructions de mise à niveau](https://www.mongodb.com/docs/manual/release-notes/7.0-upgrade-replica-set/#std-label-7.0-upgrade-replica-set), la seule exigence est d'avoir `featureCompatibilityVersion` défini sur `6.0`. Pour ce faire, ouvrez un shell MongoDB et exécutez la commande `db.adminCommand({ setFeatureCompatibilityVersion: "6.0" })` . Utilisateurs du Toolkit Overleaf : ```bash bin/mongo # ... # overleaf:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "6.0" } ) # { # "ok" : 1, # ... # } overleaf:PRIMARY> exit # au revoir ``` Nous arrêterons ensuite les instances Server CE/Server Pro et MongoDB à l'aide de la `bin/stop` commande, définir `MONGO_VERSION=7.0` dans `config/overleaf.rc`, puis redémarrer le `mongo` service à l'aide de `bin/up mongo`) pour vérifier que la mise à jour s'est déroulée sans problème. Enfin, nous mettrons à jour la version de l'image Server CE/Server Pro vers la version cible et recréerons tous les services à l'aide de la `bin/up -d` commande. **Exemple : mise à niveau de MongoDB depuis `7.0` à `8.0` (utilisateurs du toolkit)** Commencez par vous assurer que vous exécutez MongoDB `7.0` à l'aide des `commandes mongod --version` ci-dessus. Selon les [instructions de mise à niveau](https://www.mongodb.com/docs/manual/release-notes/8.0-upgrade-replica-set/#std-label-8.0-upgrade-replica-set), la seule exigence est d'avoir `featureCompatibilityVersion` défini sur `7.0`. Pour ce faire, ouvrez un shell MongoDB et exécutez la commande `db.adminCommand({ setFeatureCompatibilityVersion: "7.0", confirm: true })`. Notez que cela nécessite désormais un `confirm: true` supplémentaire. ```bash bin/mongo # ... # overleaf:PRIMARY> db.adminCommand( { setFeatureCompatibilityVersion: "7.0", confirm: true } ) # { # "ok" : 1, # ... # } overleaf:PRIMARY> exit # au revoir ``` Nous arrêterons ensuite les instances Server CE/Server Pro et MongoDB à l'aide de la `bin/stop` commande, définir `MONGO_VERSION=8.0` dans `config/overleaf.rc`, puis redémarrer le `mongo` service à l'aide de `bin/up mongo`) pour vérifier que la mise à jour s'est déroulée sans problème. Enfin, nous mettrons à jour la version de l'image Server CE/Server Pro vers la version cible et recréerons tous les services à l'aide de la `bin/up -d` commande. #### Commandes équivalentes pour les utilisateurs de docker compose Pour les utilisateurs de docker compose, la commande équivalente est : * `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 * `docker compose stop` commande pour arrêter le serveur * Modifiez le [`docker-compose.yml`](https://github.com/overleaf/overleaf/blob/4b1babd4ea634ab12c54e9a9aea7db0e8a500941/docker-compose.yml) le fichier pour utiliser `image: mongo:6.0` pour 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 déroulée sans problème * Modifiez le [`docker-compose.yml`](https://github.com/overleaf/overleaf/blob/4b1babd4ea634ab12c54e9a9aea7db0e8a500941/docker-compose.yml) le fichier pour utiliser `image: sharelatex:VERSION` pour mettre à niveau la version de l'image * `docker compose up` pour recréer tous les services. ### Création d'un rôle personnalisé Dans la version `5.5.1`, nous avons introduit une vérification au démarrage pour valider la version de compatibilité des fonctionnalités de MongoDB. Si votre base de données MongoDB utilise l'authentification (par ex. l'authentification de base), le `conteneur sharelatex.` conteneur pourrait ne pas démarrer, affichant une erreur d'autorisation "*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 autoriser l'échec de la vérification sans empêcher le démarrage du déploiement. {% hint style="success" %} Ce nouveau rôle **uniquement** accorde l'autorisation de lire les paramètres du serveur MongoDB à l'échelle du cluster et pourrait être réutilisé à des fins de surveillance, {% endhint %} {% code overflow="wrap" %} ```bash # Utilisateurs du Toolkit $ bin/docker-compose exec -it mongo mongosh -u {{YOUR-ADMIN-USERNAME}} -p # Passez à la base de données "admin" en utilisant overleaf [direct: primary] sharelatex> use admin passé à la base de données admin overleaf [direct: primary] admin> # Créez un nouveau rôle avec l'autorisation d'utiliser "getParamter". Copiez et collez la fonction ci-dessous dans le shell et appuyez sur la touche Retour db.createRole( { role: "clusterParameterReader", privileges: [ { resource: { cluster: true }, actions: ["getParameter"] } ], roles: [] } ); # Revenez à la base de données "sharelatex" use sharelatex passé à la base de données sharelatex overleaf [direct: primary] sharelatex> # Attribuez le nouveau rôle "clusterParameterReader" à votre utilisateur de base de données en copiant et collant la fonction ci-dessous dans le shell et en appuyant sur la touche Retour db.grantRolesToUser( "{{YOUR-DATABASE-USER}}", [ { role: "clusterParameterReader", db: "admin" } ] ); # Tapez exit puis retour pour quitter le shell MongoDB # Exécutez bin/up -d pour démarrer la pile de déploiement $ bin/up -d ``` {% endcode %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://overleaf-pro.ayaka.space/on-premises/fr/maintenance/updating-mongodb.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.