ApsaraDB for MongoDB:Notes sur les mises à niveau majeures de version de base de données MongoDB

Version majeure de la base de données

Modifications de compatibilité

MongoDB 8.3

• Si vous avez créé des vues ou des validateurs de collection à l'aide d'expressions, de paramètres ou de variables introduits dans MongoDB 8.3, ces vues peuvent échouer ou les objets peuvent ne pas être validés ou évalués correctement après un retour à une version antérieure.

• MongoDB 8.3 introduit une nouvelle sémantique de validation pour marquer les collections comme « validées ». Cette sémantique est incompatible avec les versions antérieures à la 8.3. Les tentatives de rétrogradation échoueront si des collections validées existent.

• À partir de MongoDB 8.3, lorsque les documents construits par l'étape $facet dépassent la limite de 100 Mo, MongoDB renvoie le code d'erreur 146 au lieu de 4031700 pour l'erreur ExceededMemoryLimit. Si votre application, pilote ou outil vérifie explicitement le code 4031700, vous devez mettre à jour votre code pour détecter le nouveau code d'erreur ExceededMemoryLimit.

• Lors du retour de MongoDB 8.3 à une version antérieure, la configuration activeBalancerWindowDOW (fenêtre de l'équilibreur de charge par jour de la semaine) n'est plus disponible.

• La commande removeShard est dépréciée. Utilisez les nouvelles commandes startShardDraining, stopShardDraining, shardDrainingStatus et commitShardRemoval pour contrôler la suppression des shards. Ces commandes prennent en charge la suspension et la reprise de la migration à tout moment.

• Sur les clusters shardés, les opérations DDL et applyOps doivent désormais s'exécuter via mongos et ne peuvent pas être exécutées directement sur les nœuds de shard.

• La valeur par défaut de 2dsphereVersion passe de 3 à 4. Pour rétrograder la version de compatibilité des fonctionnalités (FCV) en dessous de 8.3, supprimez d'abord tous les index 2dsphere de version 4.

• À partir de MongoDB 8.3 (ainsi que des versions 8.0.18 et 7.0.29), les index génériques composites appliquent des règles de validation plus strictes pour la spécification wildcardProjection. Les index existants continuent de fonctionner même s'ils ne satisfont pas aux nouvelles exigences, mais vous ne pouvez pas créer de nouveaux index qui les violent.

• Pour les collections de séries temporelles, refineCollectionShardKey exige désormais que la clé de shard référence les métadonnées logiques et le champ temporel, et n'accepte plus le format de bucket sous-jacent. Les index ne peuvent pas être nommés _id_. Le nom timeField ne peut pas commencer par $.

• La sortie de serverStatus supprime le champ service.

• Suppression de la collection système config.csrs.indexes.

Pour plus d'informations sur MongoDB 8.3, consultez la page Modifications de compatibilité dans MongoDB 8.3.

MongoDB 8.0

• Évitez d'utiliser tcmallocAggressiveMemoryDecommit.

• Le paramètre tcmallocReleaseRate vous permet de spécifier un taux de libération de mémoire. ApsaraDB for MongoDB définit cette valeur par défaut à 10 Mo/s.

• Lorsque null est utilisé comme condition de requête, MongoDB ne fait plus correspondre les valeurs undefined.

• Évitez d'utiliser les filtres d'index.

• Pour les collections de séries temporelles, évitez d'utiliser timeField comme clé de sharding.

• Évitez d'utiliser la commande cleanupOrphaned.

• N'exécutez pas de commandes compact concurrentes sur la même collection.

• Avant la mise à niveau vers MongoDB 8.0, renommez ou supprimez toute collection non temporelle nommée system.buckets.

Pour plus d'informations sur MongoDB 8.0, consultez la page Modifications de compatibilité dans MongoDB 8.0.

MongoDB 7.0

• Aucun problème de compatibilité n'existe lors de la mise à niveau vers MongoDB 7.0.

• Pour revenir d'une version majeure de MongoDB 7.0 à une version antérieure, supprimez d'abord les fonctionnalités introduites dans la version 7.0, telles que :

  • Supprimez tous les index colonnaires (columnar indexes).

  • Désenregistrez les paramètres de cluster définis à l'aide de la commande setClusterParameter. Pour plus de détails, consultez setClusterParameter.

  • Supprimez toutes les collections créées avec l'option encryptedFields.

  • Supprimez tous les index génériques composés (Compound wildcard indexes).

Pour plus d'informations sur MongoDB 7.0, consultez la page Modifications de compatibilité dans MongoDB 7.0.

MongoDB 6.0

• Si un pipeline d'agrégation utilise plus de 100 Mo de mémoire, MongoDB écrit par défaut les données dans des fichiers temporaires sur le disque. Pour modifier ce comportement, définissez le paramètre global allowDiskUseByDefault sur false.

  Les versions antérieures à 6.0 nécessitent de spécifier explicitement { allowDiskUse: true } pour écrire les données dans des fichiers temporaires sur le disque.

• Lors de l'utilisation de dropIndexes avec le caractère générique *, MongoDB ne supprime pas l'index _id ni l'index de clé de shard. Pour plus d'informations, consultez dropIndexes.

• Mongo Shell n'est plus pris en charge. Utilisez mongosh à la place.

• Les opérateurs tels que $explain, $hint, $max et $maxTimeMS ne sont plus pris en charge.

• Lorsque l'index TTL expireAfterSeconds est défini sur NaN, il est traité comme 0, ce qui peut entraîner l'expiration immédiate des documents.

• La méthode d'authentification SCRAM-SHA-1 n'est plus prise en charge.

• La commande reIndex et sa méthode correspondante reIndex() ne sont plus prises en charge.

Pour plus d'informations sur MongoDB 6.0, consultez la page Modifications de compatibilité dans MongoDB 6.0.

MongoDB 5.0

• Le niveau Read Concern pour les nœuds secondaires passe de available à local. Pour plus d'informations, consultez Read Concern.

• La valeur par défaut de Write Concern passe de 1 à majority.

  Important

  Cette modification peut dégrader les performances en écriture. Confirmez l'impact avant la mise à niveau. Vous pouvez également utiliser la commande setDefaultRWConcern pour modifier le writeConcern par défaut.

• db.collection.ensureIndex() n'est plus pris en charge. Utilisez db.collection.createIndex() à la place.

• Les paramètres des commandes saslStart et saslContinue sont désormais strictement validés et sont incompatibles avec mgo. saslContinue nécessite uniquement conversationId et payload, mais mgo fournit un paramètre supplémentaire mechanism. Pour plus d'informations, consultez mgo.

• Suppression de geoSearch.

Pour plus d'informations sur MongoDB 5.0, consultez la page Modifications de compatibilité dans MongoDB 5.0.

MongoDB 4.4

• compact ne prend plus en charge l'option force. Pour plus d'informations, consultez compact.

• geoSearch n'est plus pris en charge. Pour plus d'informations, consultez geoSearch.

• Les index peuvent désormais être créés simultanément sur les bases de données primaire et secondaire, ce qui réduit le décalage de réplication lors de la création d'index. Les secondaires restent à jour même pendant la construction des index.

Pour plus d'informations sur MongoDB 4.4, consultez la page Modifications de compatibilité dans MongoDB 4.4.

MongoDB 4.2

• geoNear n'est plus pris en charge. Utilisez $geoNear (aggregation) à la place. Pour plus d'informations, consultez $geoNear (aggregation).

• repairDatabase n'est plus pris en charge.

• cloneCollection est supprimé et n'est plus pris en charge. Utilisez mongoexport et mongoimport à la place. Pour plus d'informations, consultez mongoexport et mongoimport.

• afterClusterTime n'est plus pris en charge. Pour plus d'informations, consultez afterClusterTime.

• Les pilotes MongoDB open source 4.2+ activent les écritures retryables (Retryable Writes) par défaut. Pour plus d'informations, consultez Retryable Writes.

• Suppression de group, copydb et clone.

Pour plus d'informations sur MongoDB 4.2, consultez la rubrique Notes de mise à jour de compatibilité de MongoDB 4.2.

MongoDB 4.0

• reIndex acquiert un verrou d'écriture global jusqu'à la fin de la reconstruction de l'index. Pour plus d'informations, consultez reIndex.

• copydb et clone ne sont plus pris en charge.

Pour plus d'informations sur MongoDB 4.0, consultez la rubrique Notes de mise à jour de compatibilité de MongoDB 4.0.

MongoDB 3.6

• aggregate ne renvoie plus un seul document. Il renvoie un cursor. Vous pouvez utiliser le cursor pour spécifier la taille du lot (batch). Pour plus d'informations sur aggregate, consultez aggregate.

• $type: "array" détecte désormais directement les documents de type tableau, et pas seulement les tableaux imbriqués. Pour plus d'informations sur $type, consultez $type.

• Le comportement de tri des tableaux change comme suit :

  • find ajoute une option sort pour fournir des résultats de tri détaillés. Pour plus d'informations sur find, consultez find.

  • L'étape $sort dans $sort(aggregation) dispose d'une limite de mémoire de 100 Mo. Pour plus d'informations, consultez $sort (aggregation).

• Lors de la mise à jour de plusieurs champs en une seule opération, les nouveaux champs sont ajoutés dans l'ordre lexicographique. Pour plus d'informations, consultez $set.

• L'option de requête snapshot n'est plus prise en charge.

Pour plus d'informations sur MongoDB 3.6, consultez la rubrique Notes de mise à jour de compatibilité de MongoDB 3.6.

MongoDB 3.4

• group n'est plus pris en charge. Utilisez db.collection.aggregate() ou db.collection.mapReduce() à la place. Pour plus d'informations, consultez db.collection.aggregate() et db.collection.mapReduce().

• Utilisez l'expression $in pour faire correspondre l'opération update avec + upsert: true.

  Exemple :

  db.c.drop()
  db.c.update({a:{$in:[1]}},{$addToSet:{a:2}},{upsert:true}) // Fails in MongoDB 3.4, but succeeds in earlier versions.
  db.c.update({a:{$elemMatch:{$in:[2]}}},{$addToSet:{a:2}},{upsert:true}) // Succeeds in MongoDB 3.4.

  Pour plus d'informations sur update, consultez update.

Pour plus d'informations sur MongoDB 3.4, consultez la rubrique Modifications de compatibilité de MongoDB 3.4.