L'édition haute disponibilité de RDS s'appuie sur une architecture primaire/secondaire qui gère automatiquement le basculement. Elle constitue le choix par défaut pour les charges de travail SQL Server en production. Cette édition couvre plus de 80 % des cas d'usage dans divers secteurs, notamment les services Internet, l'IoT, le commerce en ligne, la logistique et le jeu vidéo.
Les instances secondaires de l'édition haute disponibilité de RDS sont réservées exclusivement à la reprise après sinistre et ne peuvent pas traiter le trafic de lecture. Pour acheminer les requêtes de lecture vers les instances secondaires, effectuez une mise à niveau vers l' édition Cluster de RDS et activez la répartition lecture/écriture.
Choisir une édition
Utilisez le tableau suivant pour comparer les éditions de RDS avant de créer une instance.
| Édition | Architecture | Secondaire lisible | Cas d'utilisation typique |
|---|---|---|---|
| Édition Basic de RDS | Autonome (sans standby actif) | S.O. | Développement et tests |
| Édition haute disponibilité de RDS | Primaire/secondaire | Non | Charges de travail de production nécessitant une haute disponibilité |
| Édition Cluster de RDS | Primaire/secondaire | Oui (après activation de la répartition lecture/écriture) | Lectures à forte concurrence, charges de travail intensives en lecture |
Topologie
Fonctionnement
Réplication des données
L'instance primaire réplique les données vers l'instance secondaire en mode semi-synchrone ou asynchrone. Le mode de réplication est déterminé par le modèle de paramètres que vous sélectionnez.
Pour les instances SQL Server de l'édition haute disponibilité de RDS, le mode de réplication des données peut uniquement être consulté, mais pas modifié. Si l'instance secondaire traite des charges de travail plus importantes que l'instance primaire, le mode bascule automatiquement vers le mode asynchrone.
Basculement
Si l'instance primaire devient inaccessible, ApsaraDB RDS bascule automatiquement vers l'instance secondaire.
Zones de déploiement
Déployez les instances primaires et secondaires dans différentes zones au sein de la même région pour permettre la reprise après sinistre inter-zones et améliorer la disponibilité. Les deux instances doivent rester dans la même région.
Si l'instance secondaire devient inaccessible, l'instance primaire continue d'accepter les écritures et sauvegarde les données en temps réel. Lorsque la sauvegarde approche de sa fin, la commande FLUSH TABLE WITH READ LOCK (FTWRL) s'exécute et maintient un verrou global pendant un maximum de 5 secondes, plaçant temporairement l'instance primaire en mode lecture seule.
Fonctionnalités
L'édition haute disponibilité de RDS inclut les fonctionnalités suivantes :
Sauvegarde et restauration : Sauvegardez automatiquement vos bases de données et restaurez-les à un point dans le temps antérieur.
Optimisation des performances : Accédez à des outils intégrés pour surveiller et ajuster les performances des requêtes.
SQL Explorer : Conservez les journaux de toutes les instructions SQL exécutées pendant cinq ans maximum. Utilisez ces journaux pour auditer les opérations de base de données et enquêter sur les incidents de sécurité.
Limitations
Les instances primaires et secondaires doivent se trouver dans la même région.
Les instances secondaires ne peuvent pas traiter le trafic de lecture. Cette limitation ne s'applique pas à l'édition Cluster de RDS.
Mise à niveau depuis l'édition Basic de RDS
L'édition Basic de RDS utilise une architecture autonome sans standby actif. En cas de défaillance de l'instance, de modification des spécifications ou de mise à niveau du moteur de base de données, vos charges de travail peuvent subir des temps d'arrêt prolongés.
Pour minimiser les risques de temps d'arrêt en production, effectuez une mise à niveau vers l'édition haute disponibilité de RDS. Cette mise à niveau ne nécessite ni migration des données ni récupération de l'instance d'origine.
Pour effectuer la mise à niveau, consultez la rubrique Mise à niveau de l'édition Basic vers l'édition haute disponibilité.
Pour créer directement une nouvelle instance avec l'édition haute disponibilité de RDS, consultez la rubrique Création d'une instance ApsaraDB RDS for SQL Server.
FAQ
Puis-je accéder directement à une instance secondaire ?
Non. Les instances secondaires de l'édition haute disponibilité de RDS gèrent uniquement la reprise après sinistre et ne sont pas accessibles aux services externes. Pour lire depuis les instances secondaires, effectuez une mise à niveau vers l'édition Cluster de RDS et activez la répartition lecture/écriture. Pour plus de détails, consultez la rubrique Configuration de l'attribut de lecture pour une instance RDS secondaire.
Puis-je revenir de l'édition haute disponibilité de RDS à l'édition Basic de RDS ?
Non. Le retour en arrière n'est pas pris en charge directement. Pour passer à l'édition Basic de RDS, achetez une nouvelle instance Basic, migrez vos données à l'aide de DTS, puis libérez l'instance d'origine.
Puis-je modifier le mode de réplication des données sur mon instance SQL Server ?
Non. Pour les instances SQL Server de l'édition haute disponibilité de RDS, vous pouvez consulter le mode de réplication des données, mais vous ne pouvez pas le modifier. Pour plus d'informations, consultez la rubrique Consultation et modification du mode de réplication des données.
Le mode de réplication des données passe-t-il en mode asynchrone si mon instance secondaire est fortement sollicitée ?
Oui. Si l'instance secondaire traite des charges de travail plus importantes que l'instance primaire, le mode de réplication passe automatiquement en mode asynchrone. Pour plus de détails, consultez la rubrique Modes de réplication des données.