ApsaraDB RDS for SQL Server maintient une instance secondaire synchronisée en temps réel avec l'instance principale. En cas de défaillance de l'instance principale, le système promeut automatiquement l'instance secondaire au rang de principale et votre application se reconnecte via le même endpoint, sans aucune modification des chaînes de connexion. Pour la maintenance planifiée, les mises à niveau ou les exercices de reprise après sinistre, vous pouvez également déclencher un basculement manuellement.
Prérequis
Avant de commencer, assurez-vous de disposer d'une instance RDS principale exécutant RDS High-availability Edition ou RDS Cluster Edition.
Des limitations spécifiques s'appliquent selon l'édition :
RDS Cluster Edition : seuls les basculements automatiques sont pris en charge. Pour effectuer un basculement manuel, contactez le support technique Alibaba Cloud.
RDS Basic Edition : aucune instance secondaire n'est fournie, par conséquent la fonctionnalité de basculement principal/secondaire n'est pas prise en charge.
Fonctionnement
L'instance principale gère tout le trafic en lecture et en écriture. L'instance secondaire fonctionne en mode standby et réplique continuellement les données depuis l'instance principale. Vous ne pouvez pas accéder directement à l'instance secondaire.
Lorsqu'un basculement se produit, qu'il soit automatique ou manuel, l'instance secondaire est promue au rang d'instance principale. L'endpoint utilisé pour se connecter à votre base de données reste inchangé, bien que les adresses IP associées à cet endpoint puissent changer. Si votre application se connecte via l'endpoint, elle continue de fonctionner après le basculement.
Comportement selon l'édition
|
Edition |
Basculement automatique |
Basculement manuel |
|
High-availability Edition |
Pris en charge (activé par défaut) |
Pris en charge |
|
Cluster Edition |
Pris en charge (activé par défaut) |
Non pris en charge — contactez le support technique Alibaba Cloud |
|
Basic Edition |
Non pris en charge |
Non pris en charge |
Déclencheurs d'un basculement automatique
En cas de défaillance de l'instance principale, le système bascule automatiquement vos charges de travail vers l'instance secondaire. Pour obtenir la liste complète des causes, consultez la rubrique Raisons des basculements principal/secondaire.
Limitations
Instances Serverless : les instances RDS Serverless ne prennent pas en charge les basculements manuels. Le système gère automatiquement le basculement pour les instances serverless. Pour plus de détails, consultez la rubrique Vue d'ensemble.
Synchronisation ALTER LOGIN : le mécanisme de synchronisation principal/secondaire ne réplique pas tous les paramètres de l'instruction
ALTER LOGIN. Seuls les paramètresSID,login_nameetpasswordsont synchronisés. Tous les autres paramètresALTER LOGINretrouvent leurs valeurs par défaut sur l'instance secondaire. Pour la référence complète des paramètres, consultez la documentation ALTER LOGIN (Transact-SQL).
Impacts d'un basculement
Avant d'effectuer un basculement, tenez compte des points suivants :
Interruption de service : un basculement entraîne environ 30 secondes d'indisponibilité. Configurez votre application pour qu'elle se reconnecte automatiquement à la base de données après une déconnexion. Si votre application utilise le pool de connexions Druid, mettez à jour Druid vers la version 1.1.16 ou ultérieure. Les versions antérieures peuvent échouer à se reconnecter automatiquement après une déconnexion.
Latence de réplication des instances en lecture seule : après un basculement, les instances en lecture seule rétablissent leurs connexions de réplication vers la nouvelle instance principale. Attendez-vous à une latence de réplication de quelques minutes durant cette période.
Opérations restreintes pendant le basculement : Pendant qu'un basculement est en cours, vous ne pouvez pas gérer les bases de données et les comptes, ni modifier le type de réseau.
Basculement plus long en cas de défaillance : Un basculement déclenché par une défaillance de l'instance peut prendre plus de temps qu'un basculement manuel planifié.
Modifications des adresses IP : L'endpoint reste identique, mais les adresses IP associées à l'endpoint peuvent changer. Les applications qui se connectent via l'endpoint ne sont pas affectées.
Quand effectuer un basculement manuel
Envisagez un basculement manuel dans les situations suivantes :
Maintenance et mises à niveau : Contrôlez le moment du basculement afin de minimiser l'impact de la maintenance planifiée.
Exercices de reprise après sinistre : Validez que votre application gère correctement le basculement avant qu'une défaillance réelle ne se produise.
Proximité multi-zones : Si votre instance utilise un déploiement multi-zones et que vous souhaitez que votre application se connecte à la zone la plus proche, basculez l'instance principale vers cette zone.
Effectuer un basculement manuel
Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside votre instance RDS. Localisez l'instance et cliquez sur son ID.
Dans le volet de navigation de gauche, cliquez sur Service Availability.
Dans la section Availability Information, cliquez sur Switch Primary/Secondary Instance.
-
Spécifiez le moment d'exécution du basculement, puis cliquez sur OK.
RemarqueSélectionnez Within Specified Time Range pour éviter de déclencher le basculement pendant les heures de pointe. Pendant le basculement, les opérations telles que la gestion des bases de données et des comptes ou la modification du type de réseau ne sont pas disponibles.
Désactiver temporairement les basculements automatiques
Par défaut, les basculements automatiques sont activés. Si l'instance principale tombe en panne, le système effectue immédiatement le basculement. Dans certaines situations, vous souhaiterez peut-être supprimer les basculements automatiques pour une période limitée, par exemple lors d'une promotion commerciale à grande échelle, d'une mise à niveau majeure de l'application ou durant une fenêtre d'événement critique où un basculement inattendu pourrait perturber la disponibilité.
Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside votre instance RDS. Localisez l'instance et cliquez sur son ID.
Dans le volet de navigation de gauche, cliquez sur Service Availability.
-
Dans la section Availability Information, cliquez sur Automatic Primary/Secondary Switchover.
RemarqueSi l'option Automatic Primary/Secondary Switchover n'est pas visible, vérifiez que votre instance répond à tous les prérequis.
-
Sélectionnez Temporarily Disable, définissez la Deadline, puis cliquez sur OK.
RemarqueLorsque la deadline est atteinte, les basculements automatiques sont réactivés automatiquement. Si vous laissez le champ Deadline vide, la fonctionnalité est désactivée pendant un jour. La deadline maximale est 23:59:59, sept jours à partir de maintenant.
Après l'enregistrement, la page Service Availability affiche la deadline après laquelle les basculements automatiques reprennent.
Afficher les journaux de basculement principal/secondaire
Les journaux de basculement sont uniquement disponibles pour les instances exécutant SQL Server 2008 R2 avec des disques SSD locaux Premium.
Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside votre instance RDS. Localisez l'instance et cliquez sur son ID.
Dans le volet de navigation de gauche, cliquez sur Service Availability.
Dans la section Primary/Secondary Switching Logs, sélectionnez une plage horaire pour afficher les journaux de basculement générés durant cette période.

FAQ
Dois-je revenir à l'instance principale d'origine après un basculement ?
Non. Après un basculement, l'instance secondaire devient la nouvelle instance principale et sert tout le trafic. Les deux instances conservent des données identiques grâce à la synchronisation en temps réel, il n'est donc pas nécessaire de procéder à un retour manuel.
Mon application fonctionne lentement pendant environ 10 minutes après un basculement. Quelle en est la cause ?
Cela se produit généralement parce que votre application conserve des connexions persistantes qui ne sont pas automatiquement fermées lorsque le basculement se produit. Sans configuration d'un délai d'expiration du socket, votre application attend indéfiniment une réponse de la base de données ; les connexions semblent ouvertes mais ne peuvent pas traiter les requêtes. La plupart des applications se déconnectent après plusieurs minutes, période durant laquelle les instructions SQL échouent.
Pour réduire le temps de récupération, configurez les paramètres connectTimeout et socketTimeout. Pour les charges de travail transactionnelles en ligne, définissez connectTimeout sur 1 à 2 secondes et socketTimeout sur 60 à 90 secondes. Ajustez ces valeurs en fonction des caractéristiques de votre charge de travail.
Référence API
|
Operation |
Description |
|
Bascule les charges de travail entre les nœuds principal et secondaire |
|
|
Active ou désactive les basculements automatiques principal/secondaire pour une instance |
|
|
Interroge les paramètres de basculement automatique principal/secondaire pour une instance |