ApsaraDB RDS:Automatic and manual failover

Prérequis

L'instance doit être de type Haute disponibilité ou Cluster.

Contexte

• Basculement automatique : cette fonctionnalité est activée par défaut. En cas de défaillance de l'instance principale, le système bascule automatiquement vers l'instance de secours. Pour connaître les déclencheurs d'un basculement, consultez la rubrique Causes du basculement.

• Basculement manuel : vous pouvez initier un basculement manuel même si le basculement automatique est activé. Cette option s'avère utile lors de simulations de reprise après sinistre ou pour vous connecter au nœud le plus proche dans un déploiement multi-zones.

Impact

• Un basculement principal/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, elle risque de ne 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. Ce délai s'explique par la nécessité pour RDS de reconstruire la tâche de réplication et de synchroniser les données incrémentielles.

• Un basculement principal/secondaire ne modifie pas le point de terminaison de l'instance, mais l'adresse IP sous-jacente peut changer. Nous vous recommandons d'utiliser le point de terminaison afin de garantir le bon fonctionnement de votre application pendant le basculement.

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

Effectuer un basculement manuel

1. Accédez à la page Instances. Dans la barre de navigation supérieure, sélectionnez la région où réside l'instance RDS. Localisez 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 OK.

   Remarque

   De nombreuses opérations, telles que la gestion des bases de données et des comptes ou la modification du type de réseau, sont indisponibles pendant un basculement. Pour éviter toute interruption de service, nous vous recommandons de sélectionner l'option Within Specified Time Range.

Désactiver temporairement le basculement automatique

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 de promotions commerciales majeures.

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

• Lors d'événements majeurs ou de périodes de garantie de stabilité, vous souhaitez éviter qu'un basculement principal/de secours n'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. Localisez 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 vous ne voyez pas le bouton Automatic Primary/Secondary Switchover, vérifiez que votre instance est de type Haute disponibilité.

4. Sélectionnez l'option Temporarily Disable, définissez l'heure de End Time for Temporary Disablement, puis cliquez sur OK.

   Remarque

   • Une fois l'heure spécifiée dans le champ End Time for Temporary Disablement atteinte, le basculement automatique est automatiquement réactivé.

   • Par défaut, le basculement automatique est désactivé temporairement pour une durée d'un jour. Vous pouvez définir l'heure de fin jusqu'à sept jours à compter de la date actuelle.

   Après avoir terminé la configuration, vous pouvez consulter l'heure d'expiration de la désactivation temporaire sur la page Service Availability.

Consulter les journaux de basculement principal/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. Localisez 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 horaire pour interroger les journaux.

   

FAQ

• Q : Après un basculement, dois-je revenir manuellement à l'instance principale d'origine ?

  R : Non. Les données des instances principale et de secours sont identiques. Après un basculement, l'ancienne instance de secours devient la nouvelle instance principale. Aucune autre action n'est requise.

• Q : Cela fait plus de 10 minutes qu'un basculement a eu lieu, mais le statut de l'instance n'est pas revenu à Running. Quelle en est la cause et comment résoudre ce problème ?

  R : Lors d'un basculement haute disponibilité dans ApsaraDB RDS, les connexions applicatives persistantes peuvent ne pas détecter le changement de statut. Si aucun délai d'expiration de socket n'est configuré, l'application attendra indéfiniment une réponse de la base de données, ce qui peut prendre plusieurs centaines de secondes avant la déconnexion. Pendant ce temps, certaines connexions à la base de données peuvent ne pas fonctionner correctement, entraînant de nombreuses erreurs d'exécution SQL. Pour éviter ces connexions invalides et réduire le temps d'indisponibilité, nous vous recommandons de configurer les paramètres connectTimeout et socketTimeout afin d'empêcher l'application d'attendre indéfiniment en cas d'erreur réseau.

  Les valeurs de délai d'expiration idéales dépendent de votre charge de travail métier et de vos modèles d'utilisation. Pour les charges de travail de traitement transactionnel en ligne (OLTP), un connectTimeout de 1 à 2 secondes et un socketTimeout de 60 à 90 secondes sont recommandés. Ces valeurs sont fournies à titre indicatif.

API associées