ApsaraDB RDS:Upgrade database version

Éditions RDS

ApsaraDB RDS for SQL Server est disponible en trois éditions, chacune reposant sur une architecture de disponibilité différente :

• RDS Basic Edition : Instance principale unique sans standby actif. Les modifications de spécifications et les mises à niveau de version entraînent des temps d'indisponibilité prolongés.

• RDS High-availability Edition : Instances principale et secondaire configurées en réplication semi-synchrone ou asynchrone. Basculement automatique en cas de défaillance de l'instance principale.

• RDS Cluster Edition : Architecture Always On avec séparation du calcul et du stockage. Prend en charge une ou plusieurs instances en lecture seule pour la répartition lecture/écriture.

Les fonctionnalités disponibles dépendent à la fois de la version de SQL Server et de l'édition RDS. Consultez la rubrique Fonctionnalités par version de SQL Server et édition RDS pour une comparaison complète.

Limites

Les types d'instance suivants ne peuvent pas être mis à niveau :

• Instances jointes à des domaines Active Directory (AD). Reportez-vous à la rubrique Joindre une instance RDS SQL Server à un domaine géré par l'utilisateur.

• Instances serverless. Consultez la rubrique Présentation.

• Instances sur le réseau classique. Reportez-vous à la rubrique Modifier le type de réseau.

• Instances en lecture seule.

• Instances principales disposant d'instances en lecture seule et exécutant l'édition RDS Cluster Edition. Consultez la rubrique Créer une instance en lecture seule ApsaraDB RDS for SQL Server.

Impacts de la mise à niveau

Planifiez votre fenêtre de maintenance en identifiant clairement les éléments modifiés et ceux qui restent inchangés.

Éléments modifiés :

• L'adresse IP virtuelle (VIP) de votre instance change. Utilisez le endpoint de l'instance — et non l'adresse IP — dans les chaînes de connexion de votre application pour gérer les changements de VIP de manière transparente.

• Une indisponibilité d'environ 20 minutes survient lors du basculement de la charge de travail. Assurez-vous que votre application est configurée pour se reconnecter automatiquement.

• Après la mise à niveau, videz les enregistrements DNS mis en cache sur votre client de base de données. Pour les applications basées sur JVM, définissez networkaddress.cache.ttl sur 60 secondes ou moins dans $JAVA_HOME/jre/lib/security/java.security, ou configurez ce qui suit dans le code d'initialisation de votre application avant le premier appel à InetAddress.getByName() :

  java.security.Security.setProperty("networkaddress.cache.ttl", "60");

• Les tâches Data Transmission Service (DTS) actives s'arrêtent pendant la mise à niveau. Reconfigurez-les et redémarrez-les après la mise à niveau. Consultez la rubrique Qu'est-ce que Data Transmission Service ?

Éléments inchangés :

• Le nom de l'instance, le port de connexion, les tags et les comptes de base de données restent inchangés.

Autres remarques :

• Une fois lancée, une mise à niveau ne peut pas être annulée.

• La durée de la mise à niveau dépend du volume de vos données. Consultez la section Durée estimée.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Une instance ApsaraDB RDS for SQL Server

• (Recommandé) Une instance RDS en mode paiement à l'utilisation ou serverless avec les spécifications cibles pour tester la compatibilité de l'application avant la mise à niveau

Mettre à niveau une instance

1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où se trouve votre instance. Localisez l'instance et cliquez sur son ID.

2. Dans la section Configuration Information de la page Basic Information, cliquez sur Upgrade Version. Dans la boîte de dialogue qui s'affiche, cliquez sur OK.

   Si l'option Upgrade Version n'est pas affichée, vérifiez si votre instance respecte les exigences de mise à niveau énumérées dans la section Limites .

   

3. Sur la page Upgrade Engine Version, configurez les paramètres suivants. Pour plus de détails sur les autres paramètres, consultez la section Procédure.

   Certaines versions majeures du moteur et éditions RDS peuvent être indisponibles selon la configuration actuelle de votre instance. Consultez les sections Règles de mise à niveau et Limites .

   Paramètre	Description
   Upgrade To	La version majeure cible du moteur. Les options disponibles pour Edition et Instance Type dépendent de cette sélection. Consultez la section Règles de mise à niveau.
   Edition	L'édition RDS cible. Basic Edition : Instance principale unique ; le calcul et le stockage sont découplés. High-availability Edition : Instances principale et secondaire en mode haute disponibilité. Cluster Edition : Instances principale et secondaire en mode haute disponibilité ; les instances secondaires sont accessibles en lecture. Pour une comparaison complète, consultez la rubrique Présentation.
   Instance Type	Chaque type d'instance spécifie le nombre de cœurs CPU, la capacité de mémoire, le nombre maximal de connexions et le nombre maximal d'IOPS.
   Switching Time	Switch Immediately After Data Migration : Le basculement de la charge de travail s'effectue dès que la migration des données est terminée. Switch Within Maintenance Window : Le basculement s'effectue durant la prochaine fenêtre de maintenance planifiée.

4. Lisez et acceptez les Conditions d'utilisation, puis cliquez sur Confirm Order.

Le statut de l'instance passe à Upgrading Version. Lorsque le statut revient à Running, la mise à niveau est terminée.

Durée estimée

La durée totale de la mise à niveau dépend du volume de vos données et de l'existence d'une sauvegarde complète effectuée au cours des 36 dernières heures.

Les instances SQL Server Web ne prennent pas en charge la compression des sauvegardes. Les vitesses de sauvegarde et de restauration peuvent être inférieures à 100 Go par heure.

La vitesse de sauvegarde peut varier selon la région et la période. Pour obtenir des informations plus précises sur les performances de sauvegarde et de restauration, reportez-vous au volume de données et à la durée de la dernière mise à niveau.

Exemple : Une instance avec 4 cœurs CPU, 8 Go de mémoire et 600 Go de données :

• Si aucune sauvegarde complète n'a été effectuée au cours des 36 dernières heures : ~6 heures 34 minutes au total

• Si une sauvegarde complète a été effectuée au cours des 36 dernières heures : ~3 heures 34 minutes au total

Pour réduire la durée totale de la mise à niveau, effectuez une sauvegarde complète avant de démarrer la mise à niveau ou dans les 36 heures précédant le lancement de la tâche. Consultez la rubrique Sauvegarder une instance ApsaraDB RDS for SQL Server.

L'application des journaux de transactions incrémentiels consomme beaucoup de ressources. Sur les petites instances (par exemple, 2 cœurs CPU et 4 Go de mémoire), un volume élevé de journaux de transactions peut ralentir les vitesses de restauration. Pour SQL Server 2019 et versions ultérieures, l'activation de l'option Accelerated Database Recovery peut réduire le temps de restauration de la base de données. Évaluez cette option à l'aide de la documentation officielle de Microsoft.

Bonnes pratiques

Planifiez l'opération pendant les heures creuses. Effectuez la mise à niveau durant les périodes de faible volume de transactions pour minimiser l'impact.

Évitez les transactions de longue durée. N'exécutez pas d'opérations telles que la création d'index, la reconstruction d'index ou l'archivage de données pendant la mise à niveau. Ces opérations génèrent d'importants journaux de transactions et peuvent considérablement prolonger la phase de restauration de la base de données.

FAQ

Facturation

Pour connaître les tarifs de mise à niveau, consultez la rubrique Modifier les spécifications de l'instance.

Référence API

Pour effectuer la mise à niveau via l'API, utilisez l'opération ModifyDBInstanceSpec.