Mettre à niveau la version majeure d'une base de données ApsaraDB for MongoDB - ApsaraDB for MongoDB

Précautions

Exigence de protocole : Pour mettre à niveau la version majeure d'une instance de cluster fragmenté, celle-ci doit utiliser le protocole MongoDB Protocol.
Espace disque : Avant une mise à niveau majeure de la base de données, veillez à ce que l'utilisation du disque de l'instance ne dépasse pas 90 %. La mise à niveau génère des fichiers temporaires. Si l'espace disque disponible est insuffisant (par exemple, inférieur à 20 % de la capacité totale du disque), la mise à niveau peut échouer ou provoquer des pannes de l'instance. Si l'espace disponible ne répond pas à cette exigence, augmentez d'abord la taille du disque. Ne lancez la mise à niveau qu'une fois que l'espace disque disponible atteint au moins 20 % de la capacité totale.
Processus de mise à niveau et impact :
- Redémarrages automatiques : La mise à niveau s'effectue selon un processus progressif qui redémarre automatiquement l'instance deux à trois fois. Effectuez cette opération pendant les heures creuses et assurez-vous que votre application dispose d'un mécanisme de reconnexion.
- Impact sur les performances : À partir de MongoDB 5.0, la valeur par défaut de writeConcern passe de {w:1} à {w:majority}. Si vous mettez à niveau la version majeure de votre instance de la version 4.4 vers la 5.0, vous risquez de constater une dégradation notable des performances en écriture.
  Remarque
  - Pour les mises à niveau multi-versions, par exemple de la v3.0 à la v4.2, le système effectue la mise à niveau séquentiellement via chaque version intermédiaire. Une déconnexion transitoire se produit après chaque changement de version.
  - Nous recommandons aux applications en environnement de production de se connecter à la base de données à l'aide d'un URI de chaîne de connexion.
    
    L'utilisation d'un URI de chaîne de connexion garantit que le nœud connecté est toujours le nœud principal. Cela empêche les opérations de lecture et d'écriture de votre application d'être affectées par un basculement. Pour plus d'informations sur la connexion à une base de données via un URI de chaîne de connexion, consultez les rubriques Connexion à une instance de jeu de réplicas ou Connexion à une instance de cluster fragmenté.
État de l'équilibreur de charge (Balancer) : Lors de la mise à niveau d'une instance de cluster fragmenté, l'équilibreur de charge est désactivé, puis réactivé une fois la mise à niveau terminée.
Rétrogradation de version : Il est impossible de rétrograder la version majeure après une mise à niveau.
Sauvegarde et restauration : Après la mise à niveau majeure d'une base de données, vous ne pouvez pas restaurer les données de l'instance ApsaraDB for MongoDB à partir d'une sauvegarde d'une version majeure antérieure. Vous pouvez toutefois télécharger le fichier de sauvegarde et restaurer les données dans une base de données autogérée. Pour savoir comment restaurer des données de sauvegarde dans une base de données autogérée, consultez les rubriques Restauration des données à partir d'une sauvegarde sur disque cloud ou Restauration des données à partir d'une sauvegarde sur disque local.
Durée de la mise à niveau : La durée dépend de plusieurs facteurs, tels que le volume de données, le nombre de bases de données et de tables, ainsi que l'écart entre les versions. Les estimations suivantes sont fournies à titre indicatif uniquement, car les temps réels peuvent varier.
- Instances avec disques cloud : environ 15 minutes.
- Instances avec disques locaux : pour les mises à niveau vers une version adjacente, l'opération prend quelques minutes, semblable à un redémarrage d'instance.
- Une mise à niveau vers une version adjacente, par exemple de MongoDB 3.4 à MongoDB 4.0, prend généralement entre 1 et 5 minutes. Le processus déclenche deux à trois redémarrages, chacun entraînant une déconnexion transitoire d'environ 30 secondes. La durée est indépendante de l'utilisation du disque. Effectuez la mise à niveau pendant les heures creuses et assurez-vous que l'application dispose d'un mécanisme de reconnexion.

Chemins de mise à niveau pris en charge

Vous pouvez mettre à niveau la version majeure d'une base de données depuis 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.
Architecture autonome	Usage général avec disque cloud	MongoDB 3.4	Prise en charge de 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 Lors de la mise à niveau d'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 en écriture et une augmentation de la latence en écriture. Assurez-vous 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, créez une nouvelle instance et utilisez-la 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 (soumettre un ticket pour demander)
		MongoDB 7.0	MongoDB 8.0
		MongoDB 6.0	MongoDB 7.0
		MongoDB 5.0	MongoDB 6.0
		MongoDB 4.4	MongoDB 5.0 Lors de la mise à niveau d'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 en écriture et une augmentation de la latence en écriture. Assurez-vous 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, créez une nouvelle instance et utilisez-la 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 effectuer une mise à niveau majeure impliquant un changement d'architecture ou de type de stockage, commencez par créer une instance avec la version majeure cible, puis utilisez le service 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 :

Tests de compatibilité

Avant de procéder à la mise à niveau majeure, effectuez un test de compatibilité.

Le test de mise à niveau majeure de la base de données n'est pas affecté par le fait que les instances utilisent une zone unique ou plusieurs zones. L'instance de test doit simplement se trouver dans la même région, le même VPC et disposer des mêmes spécifications d'instance que l'instance à mettre à niveau.
Vérifiez la compatibilité du pilote client avant la mise à niveau. Par exemple, lors d'une mise à niveau de MongoDB 3.4 vers MongoDB 4.0 avec une configuration de connexion Spring XML, nous vous recommandons de mettre à jour le pilote vers la version 4.11.2. Vous pouvez conserver les paramètres existants replica-set, socket-timeout et autres. Si vous utilisez encore un pilote plus ancien, tel que la version 3.3, migrez vers la version 3.6 ou ultérieure afin de garantir une prise en charge complète des nouvelles fonctionnalités.

Consultez les notes de publication de chaque version majeure présente dans votre chemin de mise à niveau et mettez à jour le code de votre client pour assurer la compatibilité.
(Facultatif) Utilisez la restauration des données pour tester la compatibilité des versions majeures.

Important
La restauration des données engendre des coûts supplémentaires.
1. Utilisez la fonction de restauration des données pour créer une nouvelle instance disposant de la même version majeure que votre instance actuelle.
2. Mettez à niveau la version majeure de la nouvelle instance.
3. Testez votre client mis à jour sur la nouvelle instance pour détecter d'éventuels problèmes de compatibilité.
  
  En cas de problèmes de compatibilité, utilisez les messages d'erreur pour déboguer et modifier le code de votre client.
4. Une fois le test terminé, libérez la nouvelle instance.

Procédure

Connectez-vous à la console ApsaraDB for MongoDB.
Dans le volet de navigation de gauche, cliquez sur Replica Set Instances ou sur Sharded Cluster Instances selon l'architecture de l'instance.
Dans le coin supérieur gauche de la page, sélectionnez le groupe de ressources et la région où se trouve votre instance.
Cliquez sur l'ID de l'instance cible, ou cliquez sur Manage dans la colonne Actions correspondant à l'instance.
Dans la section Specification Information , pointez sur Upgrade Database Version et cliquez sur la version majeure cible.
Dans la boîte de dialogue Upgrade Database Version , cliquez sur Confirm.

Remarque

Une fois la mise à niveau terminée, si la console indique toujours que l'opération est en cours, actualisez la page dans votre navigateur pour afficher le dernier statut.