Avant de procéder à la mise à niveau majeure de la version de la base de données, déterminez les versions vers lesquelles votre instance peut évoluer en fonction de son architecture et de sa version actuelle, puis examinez les modifications de compatibilité associées à chaque version.
Instructions
Chemins de mise à niveau pris en charge
-
Vous pouvez mettre à niveau la version majeure d'une base de données dans la console ApsaraDB for MongoDB. Toutefois, les versions cibles disponibles varient selon l'architecture de l'instance, son type et sa version actuelle. Voici les détails :
Architecture
Type d'instance
Version majeure actuelle
Versions de mise à niveau disponibles
Architecture autonome
Usage général avec disque cloud
MongoDB 4.0
Aucune version majeure supérieure n'est disponible pour la mise à niveau.
Usage général avec disque cloud
MongoDB 3.4
Prend en charge la mise à niveau vers MongoDB 4.0.
Architecture de jeu de réplicas
-
Usage général avec disque cloud
-
Dédié avec disque cloud
MongoDB 8.0
MongoDB 8.3
MongoDB 7.0
MongoDB 8.0
MongoDB 6.0
MongoDB 7.0
MongoDB 5.0
MongoDB 6.0
MongoDB 4.4
MongoDB 5.0
Lorsque vous mettez à niveau une instance de la v4.4 vers la v5.0, la valeur par défaut de writeConcern passe de
{w:1}à{w:majority}. Cela peut entraîner une baisse des performances d'écriture et une augmentation de la latence d'écriture. Confirmez que cet impact est acceptable avant de procéder à la mise à niveau.-
Usage général avec disque local
-
Dédié avec disque local
-
Serveur physique dédié
MongoDB 4.2
La mise à niveau sur place n'est pas prise en charge.
Pour mettre à niveau la version majeure, vous pouvez créer une nouvelle instance et l'utiliser pour remplacer l'instance d'origine.
MongoDB 4.0
MongoDB 4.2
MongoDB 3.4
-
MongoDB 4.0
-
MongoDB 4.2
MongoDB 3.2
MongoDB 3.0
Architecture de cluster fragmenté
Dédié avec disque cloud
MongoDB 8.0
MongoDB 8.3 (soumettez un ticket pour faire la demande)
MongoDB 7.0
MongoDB 8.0
MongoDB 6.0
MongoDB 7.0
MongoDB 5.0
MongoDB 6.0
MongoDB 4.4
MongoDB 5.0
Lorsque vous mettez à niveau une instance de la v4.4 vers la v5.0, la valeur par défaut de writeConcern passe de
{w:1}à{w:majority}. Cela peut entraîner une baisse des performances d'écriture et une augmentation de la latence d'écriture. Confirmez que cet impact est acceptable avant de procéder à la mise à niveau.-
Usage général avec disque local
-
Dédié avec disque local
-
Serveur physique dédié
MongoDB 4.2
La mise à niveau sur place n'est pas prise en charge.
Pour mettre à niveau la version majeure, vous pouvez créer une nouvelle instance et l'utiliser pour remplacer l'instance d'origine.
MongoDB 4.0
MongoDB 4.2
MongoDB 3.4
-
MongoDB 4.0
-
MongoDB 4.2
MongoDB 3.2
MongoDB 3.0
-
-
Si vous devez mettre à niveau la version majeure en changeant d'architecture ou de type de stockage, commencez par créer une instance avec la version majeure cible, puis utilisez Data Transmission Service (DTS) pour migrer les données de la source vers la nouvelle instance.
Consultez les rubriques suivantes pour obtenir des instructions sur la migration des données :
L'instance doit être Running pour mettre à niveau sa version majeure de base de données. Pour obtenir des instructions, consultez Mettre à niveau la version de la base de données.
Le retour à une version antérieure après une mise à niveau majeure n'est pas pris en charge.
MongoDB 4.0 et les versions ultérieures sont compatibles avec les fonctionnalités de MongoDB 3.6. Pour utiliser les fonctionnalités de MongoDB 3.6, effectuez une mise à niveau vers MongoDB 4.0 ou une version ultérieure.
Ces notes de compatibilité couvrent uniquement les modifications apportées au noyau ApsaraDB for MongoDB, et non les évolutions des fonctionnalités de gestion des instances.
-
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 de nouvelles sémantiques 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
$facetdépassent la limite de 100 Mo, MongoDB renvoie le code d'erreur 146 au lieu de 4031700 pour l'erreurExceededMemoryLimit. 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'erreurExceededMemoryLimit. -
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) devient indisponible. -
La commande
removeShardest obsolète. Utilisez les nouvelles commandesstartShardDraining,stopShardDraining,shardDrainingStatusetcommitShardRemovalpour contrôler la suppression des shards. Ces commandes permettent de suspendre et de reprendre la migration à tout moment. -
Sur les clusters shardés, les opérations DDL et
applyOpsdoivent désormais s'exécuter via mongos et ne peuvent pas être exécutées directement sur les nœuds shard. -
La valeur par défaut de
2dsphereVersionpasse 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,
refineCollectionShardKeyexige désormais que la clé de shard référence des 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 nomtimeFieldne peut pas commencer par$. -
La sortie de
serverStatussupprime le champservice. -
Suppression de la collection système
config.csrs.indexes. -
Évitez d'utiliser
tcmallocAggressiveMemoryDecommit. -
Le paramètre
tcmallocReleaseRatevous 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
nullest utilisé comme condition de requête, MongoDB ne correspond plus aux valeursundefined. -
Évitez d'utiliser les filtres d'index.
-
Pour les collections de séries temporelles, évitez d'utiliser
timeFieldcomme clé de sharding. -
Évitez d'utiliser la commande
cleanupOrphaned. -
N'exécutez pas de commandes
compactconcurrentes sur la même collection. -
Avant de passer à MongoDB 8.0, renommez ou supprimez toute collection non temporelle nommée
system.buckets. -
Aucun problème de compatibilité n'existe lors de la mise à niveau vers MongoDB 7.0.
-
Pour revenir d'une version MongoDB 7.0 à une version majeure antérieure, supprimez d'abord les fonctionnalités introduites dans la version 7.0, telles que :
-
Supprimez tous les index columnaires (
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 composites (
Compound wildcard indexes).
-
-
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
allowDiskUseByDefaultsurfalse.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
dropIndexesavec le caractère générique*, MongoDB ne supprime pas l'index_idni 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,$maxet$maxTimeMSne sont plus pris en charge. -
Lorsque l'index TTL
expireAfterSecondsest défini surNaN, il est traité comme0, ce qui peut entraîner l'expiration immédiate des documents. -
La méthode d'authentification
SCRAM-SHA-1n'est plus prise en charge. -
La commande
reIndexet sa méthode correspondantereIndex()ne sont plus prises en charge. -
Le niveau
Read Concernpour les nœuds secondaires passe deavailableàlocal. Pour plus d'informations, consultez Read Concern. -
La valeur par défaut de
Write Concernpasse de1àmajority.ImportantCette modification peut dégrader les performances en écriture. Confirmez l'impact avant la mise à niveau. Vous pouvez également utiliser la commande setDefaultRWConcern pour modifier la valeur writeConcern par défaut.
-
db.collection.ensureIndex()n'est plus pris en charge. Utilisezdb.collection.createIndex()à la place. -
Les paramètres des commandes
saslStartetsaslContinuesont désormais strictement validés et sont incompatibles avecmgo.saslContinuenécessite uniquementconversationIdetpayload, maismgofournit un paramètre supplémentairemechanism. Pour plus d'informations, consultez mgo. -
Suppression de
geoSearch. -
compactne prend plus en charge l'optionforce. Pour plus d'informations, consultez compact. -
geoSearchn'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 primaires et secondaires, réduisant ainsi le décalage de réplication lors de la création d'index. Les secondaires restent à jour même pendant la construction des index.
-
geoNearn'est plus pris en charge. Utilisez$geoNear (aggregation)à la place. Pour plus d'informations, consultez $geoNear (aggregation). -
repairDatabasen'est plus pris en charge. -
cloneCollectionest supprimé et n'est plus pris en charge. Utilisezmongoexportetmongoimportà la place. Pour plus d'informations, consultez mongoexport et mongoimport. -
afterClusterTimen'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,copydbetclone. -
reIndexacquiert un verrou d'écriture global jusqu'à la fin de la reconstruction de l'index. Pour plus d'informations, consultez reIndex. -
copydbetclonene sont plus pris en charge. -
aggregatene renvoie plus un seul document. Il renvoie uncursor. Vous pouvez utiliser lecursorpour spécifier la taille dubatch. Pour plus d'informations suraggregate, 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 :
-
findajoute une optionsortpour fournir des résultats de tri détaillés. Pour plus d'informations surfind, consultez find. -
L'
étape $sortdans$sort(aggregation)a 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
snapshotn'est plus prise en charge. -
groupn'est plus pris en charge. Utilisezdb.collection.aggregate()oudb.collection.mapReduce()à la place. Pour plus d'informations, consultez db.collection.aggregate() et db.collection.mapReduce(). -
Utilisez l'expression
$inpour faire correspondre l'opérationupdateavec+ 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.
Modifications de compatibilité entre les versions majeures
Examinez les modifications de compatibilité pour chaque version majeure de la base de données avant d'effectuer la mise à niveau :
|
Version majeure de la base de données |
Modifications de compatibilité |
|
MongoDB 8.3 |
Pour plus d'informations sur MongoDB 8.3, consultez Modifications de compatibilité dans MongoDB 8.3. |
|
MongoDB 8.0 |
Pour plus d'informations sur MongoDB 8.0, consultez Modifications de compatibilité dans MongoDB 8.0. |
|
MongoDB 7.0 |
Pour plus d'informations sur MongoDB 7.0, consultez Modifications de compatibilité dans MongoDB 7.0. |
|
MongoDB 6.0 |
Pour plus d'informations sur MongoDB 6.0, consultez Modifications de compatibilité dans MongoDB 6.0. |
|
MongoDB 5.0 |
Pour plus d'informations sur MongoDB 5.0, consultez Modifications de compatibilité dans MongoDB 5.0. |
|
MongoDB 4.4 |
Pour plus d'informations sur MongoDB 4.4, consultez Modifications de compatibilité dans MongoDB 4.4. |
|
MongoDB 4.2 |
Pour plus d'informations sur MongoDB 4.2, consultez Notes de mise à jour de compatibilité de MongoDB 4.2. |
|
MongoDB 4.0 |
Pour plus d'informations sur MongoDB 4.0, consultez Notes de mise à jour de compatibilité de MongoDB 4.0. |
|
MongoDB 3.6 |
Pour plus d'informations sur MongoDB 3.6, consultez Notes de mise à jour de compatibilité de MongoDB 3.6. |
|
MongoDB 3.4 |
Pour plus d'informations sur MongoDB 3.4, consultez Modifications de compatibilité de MongoDB 3.4. |
API associées
|
Interface |
Description |
|
Met à niveau la version majeure de la base de données d'une instance ApsaraDB for MongoDB. |