MongoDB 4.4 a atteint sa fin de vie (EOL) en février 2024. Le maintien d'une version EOL signifie que vous ne recevez plus de correctifs de sécurité, de corrections de bugs ni d'assistance technique. Plus important encore, ApsaraDB for MongoDB a documenté des bugs spécifiques au noyau et des risques opérationnels dans les versions 4.4 et antérieures — certains classés comme sévérité élevée — qui ne sont résolus que par une mise à niveau.
Migrez vers MongoDB 5.0, 6,0, 7,0 ou 8,0. Pour connaître les dates du cycle de vie des versions, consultez les Calendriers du cycle de vie.
Risques liés aux versions antérieures
L'équipe ApsaraDB for MongoDB a identifié les risques suivants sur la base de son expérience à long terme dans l'exploitation de bases de données cloud.
Les documents orphelins provoquent des incohérences de données lors de la migration
Versions concernées : Instances de cluster fragmenté exécutant MongoDB 4.2 ou version ultérieure
Version corrigée : MongoDB 4.4 ou version ultérieure
Après la migration d'un chunk depuis un shard source vers un shard de destination, le shard source conserve temporairement le chunk avant sa suppression. Toute interruption de la migration laisse derrière elle des documents orphelins. Ces documents n'affectent pas les requêtes sur les nœuds mongos, car celles-ci sont vérifiées par les données de routage des nœuds ConfigServer. Toutefois, les documents orphelins s'accumulent et entraînent des incohérences de données lors des migrations suivantes.
MongoDB 4.4 a introduit la récupération automatique des migrations de chunks et le nettoyage automatique des documents orphelins. Si des nœuds tombent en panne au milieu d'une migration, MongoDB reprend le processus automatiquement, sans qu'il soit nécessaire d'exécuter manuellement la commande cleanupOrphaned. Exécutez cette commande uniquement pour confirmer que les threads de nettoyage en arrière-plan sont actifs.
Pour plus de détails, consultez la documentation relative à cleanupOrphaned.
La commande compact bloque les lectures et les écritures
Versions concernées : Toutes les architectures exécutant MongoDB 4.2 ou version antérieure
Version corrigée : MongoDB 4.4 ou version ultérieure
L'exécution de la commande compact pour défragmenter un disque sur MongoDB 4.2 ou version antérieure bloque toutes les opérations de lecture et d'écriture pendant toute la durée du processus. L'opération ne peut pas être interrompue ; la seule option de récupération consiste donc à redémarrer l'instance, ce qui affecte la continuité des activités.
MongoDB 4.4 a optimisé le comportement de verrouillage de la commande compact afin que les opérations CRUD ne soient pas bloquées. Seules certaines opérations DDL, à savoir createIndex et dropIndex, sont brièvement impactées. Planifiez l'exécution de la commande compact en dehors de votre fenêtre de maintenance.
Pour défragmenter un disque, nous vous recommandons d'utiliser la fonctionnalité d'analyse du stockage fournie par ApsaraDB for MongoDB.
Pour plus de détails, consultez les rubriques Défragmenter les disques d'une instance et blocage compact.
La commande compact fait passer les nœuds à l'état RECOVERING
Versions concernées : Toutes les architectures dont la version majeure est MongoDB 4.2 ou antérieure et la version mineure est antérieure à 4.2.18
Version corrigée : MongoDB 4.4 ou version ultérieure
Sur les versions concernées, l'exécution de la commande compact fait passer les nœuds mongos à l'état RECOVERING. Si les nœuds restent dans cet état suffisamment longtemps, le composant d'activation d'ApsaraDB for MongoDB les considère comme non sains et déclenche une reconstruction, provoquant ainsi un temps d'arrêt imprévu.
À partir de MongoDB 4.2.18, les nœuds mongos ne passent plus à l'état RECOVERING après l'exécution de la commande compact, évitant ainsi l'indisponibilité des nœuds et les flux de reconstruction inattendus.
Pour défragmenter un disque, nous vous recommandons d'utiliser la fonctionnalité d'analyse du stockage fournie par ApsaraDB for MongoDB.
Pour plus de détails, consultez les rubriques Défragmenter les disques d'une instance et compact RECOVERING.
Les sauvegardes physiques sur les nœuds cachés consomment trop d'espace disque
Versions concernées : Toutes les architectures exécutant MongoDB 4.2 ou version antérieure utilisant des disques locaux
Version corrigée : MongoDB 5.0 ou version ultérieure (disques cloud)
Le mécanisme de sauvegarde physique sur les instances à disques locaux entraîne une augmentation continue de la taille des fichiers disque pendant le téléchargement des sauvegardes. L'accumulation de fichiers volumineux consomme un espace disque important et déclenche des alertes incorrectes d'utilisation du disque lors de pannes de nœuds ou de basculements.
Les instances à disques cloud combinent la sauvegarde physique avec des snapshots de disque, réduisant ainsi le temps nécessaire au maintien des points de contrôle de sauvegarde WiredTiger (WT) et résolvant le gonflement de l'espace disque sur les nœuds cachés. Pour les instances de jeu de réplicas contenant plus de 2 To de données, utilisez la sauvegarde par snapshot afin d'éviter les longs temps de sauvegarde, les taux d'échec élevés et les conflits d'opérations O&M associés aux sauvegardes physiques sur disques locaux.
Les données de routage résiduelles empêchent la recréation de bases de données portant le même nom
Versions concernées : Instances de cluster fragmenté exécutant MongoDB 4.4 ou version antérieure
Version corrigée : MongoDB 5.0 ou version ultérieure
Lorsque vous supprimez une base de données avec la commande dropDatabase dans un cluster fragmenté, puis que vous recréez une base de données portant le même nom, les données de routage résiduelles présentes sur le nœud ConfigServer entraînent l'échec des opérations de lecture et d'écriture.
Sur MongoDB 4.2 ou version antérieure, vous devez exécuter la commande dropDatabase à plusieurs reprises, puis exécuter la commande flushRouterConfig sur tous les nœuds mongos pour purger les données de routage. À défaut, les données résiduelles dégradent les performances.
MongoDB 5.0 a optimisé la gestion des données de routage de la commande dropDatabase de sorte que les données de routage soient automatiquement effacées, éliminant ainsi cette exigence de nettoyage manuel.
Pour plus de détails, consultez les documentations relatives à dropDatabase et flushRouterConfig.
Le write concern par défaut {w:1} provoque des échecs de synchronisation des données sur les nœuds secondaires
Versions concernées : Toutes les architectures exécutant des versions antérieures à MongoDB 5.0
Version corrigée : MongoDB 5.0 ou version ultérieure
Avec le write concern par défaut défini sur {w:1}, les données écrites rapidement sur le nœud primaire peuvent n'atteindre que partiellement les nœuds secondaires, ce qui les fait passer à l'état RECOVERING. Cela dégrade la disponibilité de l'instance, interrompt les charges de travail de séparation lecture/écriture et empêche les sauvegardes incrémentielles ainsi que la restauration à un instant donné.
MongoDB 5.0 a modifié le write concern par défaut, passant de {w:1} à {w:"majority"}. Les données ne deviennent consultables qu'après confirmation de l'écriture par la majorité des membres du jeu de réplicas, améliorant ainsi la fiabilité des données au prix d'une légère perte de performance. Pour les scénarios à haut débit d'écriture où vous pouvez accepter le comportement précédent, redéfinissez le write concern sur {w:1}.
Pour plus de détails, consultez les documentations relatives au write concern par défaut et à la commande setDefaultRWConcern.
Le balancer rééquilibre les données trop lentement pour prendre en charge la montée en charge
Versions concernées : Toutes les architectures exécutant des versions antérieures à MongoDB 5.0
Version corrigée : MongoDB 5.0 ou version ultérieure
Le balancer ne peut pas migrer les chunks assez rapidement pour rééquilibrer les données lors des événements de montée en charge, ce qui dégrade les performances car les données restent inégalement réparties entre les shards.
MongoDB 5.0 a ajouté les paramètres chunkMigrationConcurrency et balancerMigrationsThrottlingMs afin que vous puissiez ajuster la concurrence et le débit des migrations du balancer pour les adapter à votre charge de travail.
Si votre instance est déjà sous MongoDB 5.0 mais que ces paramètres ne sont pas disponibles, mettez à jour vers une version mineure ultérieure. Consultez la rubrique Mettre à jour la version mineure d'une instance.
Pour plus de détails, consultez les documentations relatives aux paramètres chunkMigrationConcurrency et balancerMigrationsThrottlingMs.
L'équilibrage basé sur le nombre de chunks provoque un déséquilibre de charge dans les clusters fragmentés
Versions concernées : Toutes les architectures dont la version majeure est MongoDB 5.0 ou antérieure et la version mineure est antérieure à 6.0.3
Version corrigée : MongoDB 6.0 ou version ultérieure
Le balancer distribue les données en fonction du nombre de chunks plutôt que du volume de données. Lorsque des chunks jumbo ou vides existent, ou lorsqu'un sous-ensemble de données reçoit un trafic disproportionnellement élevé, les chunks semblent équilibrés en nombre, mais les shards supportent une charge inégale.
MongoDB 6.0.3 a modifié le balancer pour distribuer les données en fonction de la différence de volume de données entre les shards plutôt que du nombre de chunks. Cette modification résout le déséquilibre de charge causé par les chunks jumbo, les chunks vides et les modèles de données chaudes.
Pour plus de détails, consultez l'article Modifications apportées au balancer dans MongoDB 6.0.3.
Après la mise à niveau, vous pouvez constater que les chunks ne sont plus équilibrés entre les shards ou que chaque shard ne contient qu'un seul chunk. Il s'agit du comportement attendu du nouveau balancer : vos données restent réparties de manière homogène. Pour plus de détails, consultez la rubrique Nombre de chunks déséquilibré entre les shards après une mise à niveau de MongoDB.
Autres problèmes liés au noyau
Le tableau suivant répertorie d'autres problèmes liés au noyau présents dans les versions antérieures de MongoDB, identifiés par l'équipe ApsaraDB for MongoDB.
| Version | Problème | Niveau de risque | Déclencheur et description |
|---|---|---|---|
| MongoDB 3.4 | SERVER-34192SERVER-20328SERVER-21307 | Moyen | Déclencheur : La séparation lecture/écriture est activée. Problème : Des verrous globaux sont acquis lorsque les nœuds secondaires rejouent les oplogs, provoquant des lenteurs dans les requêtes. |
| MongoDB 4.0 | SERVER-70783 | Faible | Déclencheur : Le nombre de connexions au serveur augmente considérablement. Problème : Des assertions sont déclenchées en raison d'un nombre insuffisant de sessions, provoquant des pannes et des basculements des nœuds mongos. |
| MongoDB 3.6–4,2 | SERVER-40535 | Faible | Déclencheur : Occasionnel. Problème : Erreur Cache Reader No keys found for HMAC that is valid for time ; une logique de nouvelle tentative est requise. |
| MongoDB 4.2 ou antérieur | SERVER-43641SERVER-51803 | Faible | Déclencheur : Occasionnel ; lié à /dev/urandom. Problème : Les nœuds mongos plantent et se rétablissent automatiquement après un redémarrage. |
| MongoDB 4.0–4,2 | SERVER-43889 | Faible | Déclencheur : Occasionnel. Problème : Le serveur ne peut pas distinguer les transactions des écritures pouvant faire l'objet d'une nouvelle tentative, ce qui entraîne l'échec des requêtes. |
| MongoDB 4.0–4,4 | SERVER-51281SERVER-50365 | Élevé | Déclencheur : Transactions de longue durée. Problème : Le cache d'écriture échoue à expulser les données, les lignes de cache sales dépassent 20 % et les threads de nettoyage des transactions se bloquent, entraînant une augmentation significative de la latence des requêtes et une dégradation des performances. |
| MongoDB 3.6–4,4 | SERVER-52654 | Élevé | Déclencheur : Les nœuds ConfigServer n'ont pas effectué de basculement depuis 90 jours. Problème : Les échecs de génération de clés HMAC (Hash-based Message Authentication Code) sur les nœuds ConfigServer provoquent le plantage des nœuds mongos, qui ne parviennent pas à se rétablir automatiquement. |
| MongoDB 4.0–4,4 | SERVER-53566 | Moyen | Déclencheur : Occasionnel. Problème : Une erreur d'assertion opContext provoque le plantage de mongod et déclenche un basculement. |
| MongoDB 4.4 ou antérieur | SERVER-21307 | Élevé | Déclencheur : Les opérations DDL sont enregistrées dans les oplogs lors de la création d'index en arrière-plan sur les nœuds secondaires. Problème : Les opérations DDL sont bloquées et les nœuds secondaires tombent en panne. |
| MongoDB 4.4 ou antérieur | WT-5809 | Moyen | Déclencheur : Redémarrage du nœud ou initialisation de la synchronisation des données. Problème : Des problèmes d'ordre temporel dans le magasin d'historique WiredTiger déclenchent une erreur d'assertion WT, provoquant le plantage de mongod. |
| MongoDB 4.2–4,4 | SERVER-51041 | Élevé | Déclencheur : La séparation lecture/écriture est activée et la charge des nœuds secondaires est élevée. Problème : La contention des mutex de threads POSIX épuise les tickets de lecture sur les nœuds secondaires, dégradant les performances. |
| MongoDB 4.2–4,4 | SERVER-52556SERVER-66176 | Moyen | Déclencheur : L'application appelle fréquemment la commande listCollections. Problème : La contention des verrous mutex dans le composant CollectionCatalog sous-jacent dégrade considérablement les performances. |
| MongoDB 6.0 ou antérieur | SERVER-63865SERVER-67038SERVER-69877 | Élevé | Déclencheur : Erreur d'épuisement de la mémoire (OOM) lors de la création d'index. Problème : mongod redémarre de manière répétée et ne parvient pas à se rétablir. Si deux nœuds d'un jeu de réplicas entrent dans cet état, l'instance devient indisponible. |
| MongoDB 6.0 ou antérieur | SERVER-56194 | Faible | Déclencheur : Grand nombre de documents expirés après la création d'indexes TTL (Time to Live) ou la modification des délais d'expiration. Problème : Les threads TTL en arrière-plan se bloquent et ne parviennent pas à se rétablir, ce qui entraîne l'arrêt du fonctionnement de la fonctionnalité TTL. |
Nouvelles fonctionnalités des versions ultérieures
| Version | Fonctionnalité | Description |
|---|---|---|
| MongoDB 5.0 | Collections de séries temporelles | Stockage et interrogation efficaces des données de séries temporelles pour les scénarios Internet des Véhicules (IoV) et Internet des Objets (IoT). |
| Requêtes de snapshot de longue durée | Consultez des snapshots historiques sans affecter les opérations en cours. | |
| API versionnée | Découple le cycle de vie de l'application de celui de la base de données. Les applications restent entièrement compatibles lors des mises à niveau de version de la base de données, sans nécessiter de remédiation de compatibilité. | |
| MongoDB 6.0 | Change streams | Les vues pré-changement sont désormais disponibles. L'efficacité d'exécution et l'utilisation des ressources sont améliorées. Les mises à jour de documents orphelins peuvent être filtrées. Davantage d'événements de changement DDL sont pris en charge, renforçant ainsi la prise en charge de la Capture de Données Modifiées (CDC). |
| Requêtes JOIN dans les clusters fragmentés | Les instances de cluster fragmenté prennent en charge les opérateurs $lookup et $graphLookup pour les requêtes JOIN, avec des performances d'opérateur améliorées. |
|
| Défragmentation automatique dans les clusters fragmentés | Utilisez la commande configureCollectionBalancing pour spécifier la taille des chunks par shard et activer la défragmentation automatique, sans avoir besoin d'exécuter manuellement la commande compact dans les clusters fragmentés. |
|
| Améliorations des collections de séries temporelles | Prise en charge du sharding, compression colonnaire pour réduire l'utilisation du stockage, index secondaires et composites pour améliorer les performances de lecture, index géospatiaux pour les données spatio-temporelles et tri optimisé des séries temporelles. | |
Commande compact améliorée |
Optimisation complète de la commande compact dans WiredTiger, avec des performances nettement améliorées et moins d'échecs dus à l'éviction. |
|
| MongoDB 7.0 | Analyse de la clé de shard | Analysez les résultats de requêtes échantillonnés pour évaluer si la clé de shard d'une collection est optimale. Utilisez cette fonction pour configurer les schémas et les clés de shard plus efficacement. |
| Chiffrement interrogeable | Chiffre les données sensibles tout au long de leur cycle de vie : en transit, au repos, en cours d'utilisation, dans les journaux et dans les sauvegardes. Les données ne sont déchiffrées que sur le client, réduisant considérablement les risques de fuite de données en cas de vol. | |
| Vérification de la cohérence des métadonnées | Détecte automatiquement les incohérences de métadonnées et d'index après la fin d'une fenêtre de maintenance ou après des exceptions telles que des erreurs OOM ou des basculements. | |
| Événements de changement volumineux dans les change streams | L'opérateur $changeStreamSplitLargeEvent divise les événements de changement supérieurs à 16 Mo, résolvant ainsi la limitation des versions antérieures où les événements volumineux provoquaient l'échec des change streams. |
|
| Limitation dynamique dans WiredTiger | Ajuste dynamiquement la concurrence des transactions WiredTiger (par défaut : 128) pour éviter les pannes de base de données dues à l'accumulation de requêtes après des exceptions. | |
| MongoDB 8.0 | TCMalloc avancé | Utilise des caches par CPU au lieu de caches par thread pour réduire la fragmentation de la mémoire et gérer des charges de travail plus lourdes. Un thread en arrière-plan libère la mémoire vers le système d'exploitation chaque seconde. |
| Performance de réplication optimisée | Avec le write concern défini sur majority, MongoDB renvoie la réponse après l'écriture des oplogs sur la plupart des membres du jeu de réplicas, sans attendre l'application effective du changement, ce qui améliore le débit d'écriture. Les nœuds secondaires écrivent et appliquent également les lots d'oplog en parallèle : un thread Writer lit depuis le primaire et écrit dans l'oplog local, tandis qu'un thread Applier applique les changements de manière asynchrone à la base de données locale. |
|
| Resharding optimisé | Performances améliorées de la commande reshardCollection pour modifier la clé de shard et la distribution des données d'une collection. |