Aller au contenu

AWS Mis à jour le 2026-07-04

Basculement RDS inattendu : ce qui déclenche le basculement Multi-AZ et comment lire les événements

Une instance RDS Multi-AZ a basculé sans que personne le demande. Voici ce qui déclenche réellement un basculement, comment lire le journal d'événements RDS pour trouver la cause, et pourquoi certaines applications restent cassées après.

Un basculement RDS Multi-AZ que vous n’avez pas initié est déclenché par une courte liste de choses : l’hôte principal ou son stockage a lâché, la zone de disponibilité a eu un problème, l’OS ou l’instance a été mis à jour, la classe d’instance a été modifiée, ou le principal est devenu non réactif assez longtemps pour que les vérifications de santé de RDS abandonnent. Le dossier qui fait autorité est le journal d’événements RDS — aws rds describe-events — qui nomme le déclencheur en texte clair. Le basculement lui-même, c’est le système qui fonctionne comme prévu; l’enquête consiste à déterminer si le déclencheur est bénin et pourquoi votre application l’a remarqué plus qu’elle n’aurait dû.

Ce qui se passe

Dans un déploiement Multi-AZ de type instance, RDS maintient un standby répliqué de façon synchrone dans une autre zone de disponibilité. Quand RDS juge le principal malsain — ou qu’une opération l’exige — il promeut le standby et repointe le DNS du point de terminaison vers lui. Le nom d’hôte ne change jamais; l’adresse IP derrière, oui. Le basculement se termine typiquement en 60-120 secondes pour les déploiements Multi-AZ de type instance; les déploiements Multi-AZ de type cluster (la variante à deux standbys lisibles) basculent typiquement plus vite, habituellement sous 35 secondes.

Les déclencheurs documentés : une panne ou une dégradation réseau de la zone de disponibilité; une défaillance matérielle de l’hôte principal; une défaillance du stockage du principal; le processus de base de données qui plante ou gèle au-delà de la tolérance des vérifications de santé (une terminaison par manque de mémoire au niveau de l’OS est un classique — le moteur est mort, RDS a basculé, et la cause était la pression mémoire, pas AWS); les opérations que vous ou votre automatisation avez lancées — modification de classe d’instance, maintenance de l’OS, redémarrage avec basculement; et le reboot-db-instance --force-failover manuel.

Deux choses font qu’un basculement propre ressemble à une panne. D’abord, le DNS : les clients qui ont mis en cache l’ancienne IP — les JVM avec leur cache de résolution par défaut, les pools de connexions qui ne recyclent jamais, tout ce qui a résolu une fois au démarrage — continuent de marteler une adresse morte longtemps après que le standby soit en service. Ensuite, les écritures en vol au moment du basculement sont annulées, et les applications sans logique de nouvelle tentative les exposent comme des erreurs aux utilisateurs.

Quoi vérifier en premier

  • Le journal d’événements RDS — RDS > Events, ou la CLI ci-dessous. Les événements de basculement énoncent la raison; c’est la seule source de vérité.
  • Le moment vs votre fenêtre de maintenance — un basculement dans la fenêtre pendant une semaine de maintenance en attente, c’est presque certainement du rapiéçage, pas une panne.
  • FreeableMemory et SwapUsage avant l’événement — une spirale mémoire précédant le basculement signifie que le déclencheur était votre charge, et que ça se reproduira.
  • Si l’application s’est rétablie seule — si la base était revenue en deux minutes mais que les erreurs ont duré quarante, votre vrai problème est le cache DNS côté client ou l’absence de nouvelles tentatives.
  • Le tableau de bord AWS Health à health.aws.amazon.com pour les événements de zone qui expliqueraient des défaillances d’hôte ou de réseau.

Comment vérifier

Tirez les événements autour de l’incident :

aws rds describe-events \
  --source-identifier prod-db \
  --source-type db-instance \
  --start-time 2026-07-03T00:00:00Z \
  --end-time 2026-07-04T12:00:00Z \
  --query 'Events[].[Date,Message]' --output table

Vous cherchez des paires comme Multi-AZ instance failover started / Multi-AZ instance failover completed, et les messages autour : remplacement d’hôte, défaillance de stockage, « Recovery of the DB instance has started », ou une action de maintenance appliquée. Confirmez quelle zone est principale maintenant :

aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[AvailabilityZone,SecondaryAvailabilityZone,MultiAZ]'

Recoupez l’histoire mémoire dans CloudWatch :

aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name FreeableMemory \
  --dimensions Name=DBInstanceIdentifier,Value=prod-db \
  --start-time 2026-07-03T00:00:00Z --end-time 2026-07-04T00:00:00Z \
  --period 300 --statistics Minimum

Le runbook

  1. Lire le journal d’événements avant de théoriser. Le déclencheur est habituellement énoncé tel quel. Remplacement d’hôte et problèmes de zone sont du côté AWS et bénins isolément; plantages du moteur et pression mémoire sont à vous de corriger.
  2. Classer le déclencheur. Défaillance d’infrastructure ponctuelle : notez-la et passez à autre chose — c’est précisément à ça que sert le Multi-AZ. Causé par la maintenance : votre fenêtre et vos réglages de notification méritent attention, couverts dans les fenêtres de maintenance RDS. Causé par la charge (OOM, gel) : ouvrez une enquête de performance — voyez RDS à court de mémoire.
  3. Corriger la gestion DNS des clients. Réglez networkaddress.cache.ttl de la JVM à 30 ou moins, assurez-vous que les pools valident les connexions à l’emprunt et recyclent en cas d’échec, et ne résolvez jamais le point de terminaison une seule fois au démarrage. C’est le correctif le plus rentable de cette page.
  4. Ajouter des nouvelles tentatives avec recul pour les écritures. Les transactions interrompues par le basculement s’annulent proprement; une application qui réessaie de façon idempotente transforme un basculement en soubresaut de latence au lieu d’une page d’erreur.
  5. S’abonner aux événements de basculement. aws rds create-event-subscription --subscription-name prod-db-failover --sns-topic-arn arn:aws:sns:ca-central-1:123456789012:ops --source-type db-instance --event-categories failover failure — pour que le prochain vous alerte avant les clients.
  6. Faire l’exercice. Lancez aws rds reboot-db-instance --db-instance-identifier staging-db --force-failover contre l’environnement de pré-production chaque trimestre et mesurez le temps de rétablissement applicatif. Si la pré-production prend dix minutes à se remettre d’un basculement de deux minutes, la production aussi.

Quand c’est la mauvaise approche

Ne traitez pas un basculement isolé avec une explication propre côté AWS comme une crise de fiabilité — courir après un remplacement matériel de zone avec des changements d’architecture, c’est de l’effort dépensé sur un problème déjà résolu. À l’inverse, ne normalisez pas les basculements répétés : deux ou plus dans un mois avec des messages « recovery started » et aucune corrélation AWS Health, ça veut dire que le principal n’arrête pas de mourir, et la cause est presque toujours dans votre charge ou vos paramètres. Et si vos exigences de temps de rétablissement sont plus strictes que 60-120 secondes d’indisponibilité en écriture, la conversation honnête, c’est l’architecture — déploiements Multi-AZ de type cluster ou Aurora — qu’on a comparés dans Multi-AZ vs Multi-Région. Le comportement de basculement par moteur est documenté dans la documentation Amazon RDS.

Erreurs fréquentes

  • Blâmer AWS par défaut sans jamais lire describe-events, où la vraie raison attendait depuis le début.
  • Laisser le cache DNS de la JVM ou de l’OS aux valeurs par défaut, transformant chaque basculement de 90 secondes en panne applicative de 30 minutes.
  • Ne jamais tester le basculement, puis découvrir pendant un vrai que l’application garde ses connexions ouvertes jusqu’à ce qu’elles pourrissent.
  • Supposer que Multi-AZ signifie aucune interruption — ça signifie un rétablissement rapide avec une brève coupure d’écriture, et les transactions en vol s’annulent quand même.

Prévention

  • Abonnements aux événements des catégories failover et failure branchés sur le canal de garde.
  • Côté client : TTL DNS courts, validation des connexions à l’emprunt, nouvelles tentatives avec recul sur les écritures.
  • Surveillez les tendances de FreeableMemory, SwapUsage et du CPU — la plupart des basculements « mystères » sont précédés de semaines de pression visible.
  • Exercices trimestriels de basculement forcé en pré-production avec une cible mesurée de rétablissement applicatif.
  • Gardez les fenêtres de maintenance dans une vraie heure creuse pour que les basculements planifiés tombent quand personne ne regarde les tableaux de bord avec colère.

Un basculement Multi-AZ, c’est la plateforme qui tient une promesse; le journal d’événements vous dit pourquoi elle a dû le faire, et les correctifs côté client décident si quelqu’un le remarquera la prochaine fois. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.