Tous les produits
Search
Centre de documentation

ApsaraDB RDS:Use the primary/secondary switchover feature

Dernière mise à jour :Aug 21, 2026

ApsaraDB RDS for PostgreSQL bascule automatiquement les charges de travail de l'instance principale vers l'instance secondaire en cas de défaillance de l'instance principale. Après le basculement, l'instance secondaire devient la nouvelle instance principale et vos endpoints de connexion restent inchangés, ce qui permet à votre application de se reconnecter automatiquement. Vous pouvez également déclencher un basculement manuel pour des exercices de reprise après sinistre ou pour réduire la latence avec des déploiements multi-zones.

Prérequis

Avant de commencer, assurez-vous d'avoir :

  • Une instance RDS exécutant RDS High-availability Edition ou RDS Cluster Edition

RDS Basic Edition ne provisionne pas d'instance secondaire et ne prend pas en charge les basculements primaire/secondaire.
Dans une instance RDS for MySQL exécutant RDS High-availability Edition, les données sont synchronisées entre le nœud principal et le nœud secondaire en temps réel. Vous pouvez accéder uniquement au nœud principal de l'instance. Le nœud secondaire fonctionne uniquement en tant que secours et ne peut pas être accédé directement.

Impacts potentiels

Avant de déclencher un basculement, prenez connaissance des effets suivants :

  • Interruption de service : Un basculement entraîne environ 30 secondes d'indisponibilité. Il peut prendre plus de temps lorsqu'une instance tombe en panne. Configurez votre application pour qu'elle se reconnecte automatiquement après une déconnexion. Si votre application utilise le pool de connexions Druid, mettez à niveau Druid vers la version 1.1.16 ou ultérieure pour vous assurer que la reconnexion automatique fonctionne correctement.

  • Décalage 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 à quelques minutes de décalage des données sur les instances en lecture seule.

  • Stabilité des endpoints : Les endpoints de connexion restent inchangés après un basculement. Les adresses IP associées à ces endpoints peuvent changer ; connectez-vous donc en utilisant le nom d'hôte de l'endpoint plutôt que l'adresse IP.

Déclencher un basculement manuel

Déclenchez un basculement manuel pour des exercices de reprise après sinistre, ou lorsque vous utilisez un déploiement multi-zone et souhaitez que l'application se connecte à l'instance dans la zone la plus proche.

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

  2. Dans le volet de navigation de gauche, cliquez sur Service Availability.

  3. Dans la section Availability Information, cliquez sur Switch Primary/Secondary Instance.

  4. Définissez le paramètre Switching Time et cliquez sur OK.

    Nous vous recommandons de sélectionner Switch Within Maintenance Window .
    Option Description
    Switch Now Déclenche le basculement immédiatement.
    Switch Within Maintenance Window Reporte le basculement à la prochaine fenêtre de maintenance afin de minimiser l'impact sur les charges de travail en cours d'exécution.
Pendant un basculement, les opérations telles que la gestion des bases de données et des comptes ainsi que les modifications du type de réseau ne sont pas disponibles.

Désactiver temporairement les basculements automatiques

Par défaut, les basculements automatiques primaire/secondaire sont activés. Lorsque l'instance principale tombe en panne, le système bascule automatiquement les charges de travail vers l'instance secondaire. Pour plus d'informations sur les causes des basculements primaire/secondaire, consultez Raisons des basculements primaire/secondaire. Vous pouvez désactiver temporairement ce comportement dans les scénarios suivants :

  • Une promotion commerciale à grande échelle

  • Une mise à niveau critique d'application

  • Un événement majeur nécessitant une connectivité stable à la base de données

Seules les éditions RDS High-availability Edition avec disques cloud et RDS Cluster Edition avec disques cloud prennent en charge la désactivation temporaire des basculements automatiques.

Pour désactiver les basculements automatiques :

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

  2. Dans le volet de navigation de gauche, cliquez sur Service Availability.

  3. Dans la section Availability Information, cliquez sur Configure Primary/Secondary Switchover.

    Si Configure Primary/Secondary Switchover n'est pas affiché, vérifiez que votre instance exécute RDS High-availability Edition.
  4. Sélectionnez Disable Temporarily, définissez le paramètre Deadline et cliquez sur OK.

    Les basculements automatiques sont réactivés lorsque la date limite est atteinte. Si vous ne définissez pas de date limite, les basculements automatiques sont désactivés par défaut pendant un jour. La date limite maximale est 23:59:59 dans sept jours.

Après l'enregistrement, la date limite s'affiche sur la page Service Availability afin que vous puissiez confirmer quand les basculements automatiques reprendront.

Afficher les journaux de basculement

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

  2. Dans le volet de navigation de gauche, cliquez sur Service Availability.

  3. 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.

image.png

Les instances en lecture seule exécutant RDS High-availability Edition prennent également en charge l'affichage des journaux de basculement primaire/secondaire.

FAQ

Dois-je rebasculer les charges de travail vers l'instance principale d'origine après un basculement ?

Non. Après un basculement, l'instance secondaire devient la nouvelle instance principale avec les mêmes données. Aucune action supplémentaire n'est requise.

Après un basculement, mon application se comporte anormalement pendant plusieurs minutes. Quelle en est la cause et comment y remédier ?

Cela se produit généralement lorsque les connexions socket n'ont pas de délai d'expiration configuré. Sans délai d'expiration, votre application attend indéfiniment les réponses de la base de données après l'invalidation des anciennes connexions, ce qui entraîne la mise en file d'attente et l'échec des instructions SQL.

Définissez connectTimeout et socketTimeout sur vos connexions de base de données pour limiter la durée d'attente de l'application lors d'erreurs réseau. 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 de votre charge de travail réelle et de vos exigences de latence.

Référence API

Operation Description
SwitchDBInstanceHA Bascule les charges de travail entre les instances principales et secondaires
ModifyHASwitchConfig Active ou désactive les basculements automatiques primaire/secondaire
DescribeHASwitchConfig Interroge les paramètres de basculement automatique pour une instance