ApsaraDB RDS:Gérer le basculement primaire/secondaire

Prérequis

• Si l'instance est une instance standard, elle doit appartenir à l'une des éditions suivantes :

  • Série Haute disponibilité

  • Édition Enterprise RDS

  • Édition Cluster

  Remarque

  Les instances de la série Basique ne disposent pas de nœud secondaire et ne prennent donc pas en charge le basculement primaire/secondaire.

• Si l'instance est une instance en lecture seule, elle doit appartenir à la série Haute disponibilité et utiliser la classe de stockage sur disque cloud.

Informations générales

• Basculement automatique : cette fonctionnalité est activée par défaut. Si le nœud principal tombe en panne, RDS bascule automatiquement les charges de travail vers le nœud secondaire. Pour plus d'informations sur les déclencheurs d'un basculement primaire/secondaire, consultez la rubrique Raisons du basculement primaire/secondaire.

• Basculement manuel : même si le basculement automatique est activé, vous pouvez effectuer manuellement un basculement primaire/secondaire. Le basculement manuel est utile pour les exercices de reprise après sinistre ou pour des scénarios tels que la connexion depuis la zone la plus proche dans un déploiement multizone.

Pour obtenir des informations sur le basculement primaire/secondaire pour d'autres moteurs de base de données, consultez les rubriques suivantes :

• Basculement primaire/secondaire SQL Server

• Basculement primaire/secondaire automatique ou manuel PostgreSQL

• Basculement primaire/secondaire MariaDB

Impact

• Un basculement primaire/secondaire entraîne une interruption de service qui dure généralement 15 secondes ou moins. Assurez-vous que votre application dispose d'un mécanisme de reconnexion automatique.

  Si votre application utilise une ancienne version du composant Druid pour la gestion des connexions à la base de données, il se peut qu'elle ne parvienne pas à se reconnecter automatiquement après une déconnexion. Pour éviter ce problème, mettez à niveau le composant Druid vers la version 1.1.16 ou ultérieure.

• Si l'instance principale possède des instances en lecture seule associées, ces dernières peuvent subir un retard de données de plusieurs minutes après le basculement. En effet, RDS doit reconstruire la tâche de réplication et synchroniser les données incrémentielles.

• Un basculement primaire/secondaire ne modifie pas l'endpoint de l'instance, mais l'adresse IP sous-jacente peut changer. Nous vous recommandons d'utiliser l'endpoint pour garantir que votre application continue de fonctionner comme prévu pendant le basculement.

• En cas de panne grave de l'instance, le basculement peut prendre plus de temps que d'habitude.

Basculer manuellement les nœuds principal et secondaire

1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside l'instance RDS. Recherchez ensuite l'instance RDS 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. Sélectionnez une heure de basculement et cliquez sur Confirm.

   Important

   Lors d'un basculement primaire/secondaire, vous ne pouvez pas effectuer d'opérations telles que la gestion des bases de données et des comptes ou la modification du type de réseau. Nous vous recommandons de sélectionner Switch immediately using current settings.

   Pour les instances de l'édition Cluster, vous pouvez également effectuer un basculement primaire/secondaire à partir du diagramme de topologie de l'instance sur la page Basic Information.

Désactiver temporairement le basculement automatique primaire/secondaire

Le basculement automatique est activé par défaut. Lorsque le nœud principal tombe en panne, RDS bascule automatiquement vers le nœud secondaire. Vous pouvez désactiver temporairement le basculement automatique dans les scénarios suivants :

• Pour éviter tout impact sur la disponibilité du système lors des grandes promotions commerciales.

• Pour empêcher qu'un basculement n'introduise des variables inattendues lors de mises à niveau critiques des applications.

• Lors d'événements majeurs ou de périodes d'assurance de la stabilité, vous ne souhaitez pas qu'un basculement primaire/de secours affecte la stabilité du système.

1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside l'instance RDS. Recherchez ensuite l'instance RDS 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 Automatic Primary/Secondary Switchover.

   Remarque

   Si le bouton Automatic Primary/Secondary Switchover n'est pas affiché, assurez-vous que votre instance répond aux prérequis décrits dans cette rubrique.

4. Sélectionnez Temporarily Disable, définissez l'heure de fin dans le champ Disable Until, puis cliquez sur Confirm.

   Remarque

   • Le basculement automatique primaire/secondaire est automatiquement réactivé après l'heure spécifiée dans le champ Disable Until.

   • La période de désactivation par défaut est d'un jour. Vous pouvez définir une période de désactivation allant jusqu'à sept jours. La période de désactivation prend fin à 23:59:59 le dernier jour.

Une fois la configuration terminée, vous pouvez consulter l'heure d'expiration de la désactivation temporaire sur la page Service Availability.

Consulter les journaux de basculement primaire/secondaire

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

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

3. Dans la section Primary/Secondary Switchover Logs, spécifiez une plage de temps pour interroger les journaux.

   

FAQ

• Q : Puis-je accéder au nœud secondaire ?

  R : Vous ne pouvez accéder aux nœuds secondaires que pour les instances de l'édition Cluster. Les nœuds secondaires des autres éditions d'instance ne sont pas accessibles.

• Q : Après un basculement primaire/secondaire, dois-je revenir manuellement au nœud principal d'origine ?

  R : Non. Les données sur les nœuds principal et secondaire sont entièrement synchronisées. Après le basculement, l'ancien nœud secondaire devient le nouveau nœud principal. Aucune action supplémentaire n'est requise.

• Q : Après un basculement primaire/de secours, l'état de l'instance n'est pas revenu à Running depuis plus de 10 minutes. Quelles en sont les causes possibles et comment résoudre le problème ?

  Lorsqu'un événement anormal déclenche un basculement de haute disponibilité (HA) dans RDS, les connexions persistantes de l'application peuvent ne pas détecter les changements d'état de la connexion. Si vous ne configurez pas de valeur de délai d'attente de socket, l'application attend indéfiniment que la base de données renvoie un résultat, expirant généralement après plusieurs centaines de secondes. Pendant cette période, certaines connexions à la base de données deviennent indisponibles et les instructions SQL échouent fréquemment. Pour éviter les connexions invalides, nous vous recommandons de configurer connectTimeout et socketTimeout afin d'éviter une attente indéfinie en cas d'erreurs réseau, réduisant ainsi les temps d'arrêt.

  Définissez les valeurs de délai d'attente en fonction de votre charge de travail et de vos modèles d'utilisation. Pour les scénarios de traitement transactionnel en ligne (OLTP), nous vous recommandons de définir connectTimeout sur 1 à 2 secondes et socketTimeout sur 60 à 90 secondes. Ces valeurs sont fournies à titre indicatif uniquement.

API associées