Aller au contenu

AWS Mis à jour le 2026-07-04

Fenêtres de maintenance RDS : ce qui redémarre vraiment et comment planifier autour

Tout ne redémarre pas la base de données pendant une fenêtre de maintenance RDS. Voici quelles actions de maintenance causent une interruption, comment le Multi-AZ change le calcul, et comment planifier et reporter la maintenance délibérément.

La fenêtre de maintenance RDS est un créneau hebdomadaire d’au moins 30 minutes pendant lequel AWS a la permission d’appliquer la maintenance en attente — la plupart des semaines, il ne s’y passe rien du tout. Quand quelque chose s’y passe, l’impact va de nul (bien des changements réseau et côté hôte) à un redémarrage complet (mises à niveau mineures du moteur, certains correctifs d’OS). En Multi-AZ, la maintenance de classe redémarrage est appliquée d’abord au standby, suivie d’un basculement, ce qui réduit des minutes d’interruption à environ la durée d’un basculement. La compétence opérationnelle : savoir ce qui est en attente, ce que ça fera, et choisir quand ça tombe au lieu d’être surpris.

Ce qui se passe

Trois mécanismes distincts se retrouvent confondus sous « maintenance », et les démêler apporte l’essentiel de la clarté :

La fenêtre de maintenance (PreferredMaintenanceWindow) est un créneau hebdomadaire, minimum 30 minutes. Si vous n’en avez jamais défini, AWS a assigné un créneau aléatoire par région — c’est comme ça que des bases finissent par se faire rapiécer le mardi à 9 h, heure locale. La fenêtre est le moment où les actions en attente peuvent s’exécuter; une file vide signifie une fenêtre sans histoire.

Les actions de maintenance en attente forment la file : correctifs d’OS, mises à jour du matériel/hôte sous-jacent, rotations de certificats et correctifs obligatoires du moteur. Chaque action porte un type et une urgence — certaines sont available (appliquez quand vous voulez), certaines ont une AutoAppliedAfterDate (application dans une fenêtre après cette date), et de rares actions critiques de sécurité sont forced avec une échéance. Vous pouvez appliquer n’importe laquelle en avance, à votre horaire, au lieu d’attendre d’être cédulé.

La mise à niveau mineure automatique (AutoMinorVersionUpgrade) est un indicateur par instance : à vrai, RDS met le moteur à niveau vers la version mineure préférée courante pendant une fenêtre dès qu’il juge la version admissible. Les mises à niveau mineures redémarrent le moteur. Cet indicateur, laissé à sa valeur par défaut (activé), est la source numéro un de « la base a redémarré et personne ne savait pourquoi ».

Ce qui redémarre et ce qui ne redémarre pas : mises à niveau mineures du moteur — redémarrage, toujours. Maintenance OS/hôte — parfois un redémarrage ou un remplacement d’hôte, précisé par action. Rotation du certificat CA — exige un redémarrage pour que l’instance prenne le nouveau certificat. Les changements de paramètres statiques du groupe de paramètres attendent votre redémarrage, pas la fenêtre. Et l’agrandissement du stockage ne redémarre pas l’instance du tout.

Le Multi-AZ change l’arithmétique : pour la maintenance de classe redémarrage, RDS rapièce le standby, bascule, puis rapièce l’ancien principal — l’interruption visible pour les clients est donc un basculement (couramment moins d’une minute ou deux) plutôt qu’un cycle complet de rapiéçage mono-instance. Les instances mono-AZ prennent tout le redémarrage en interruption.

Quoi vérifier en premier

  • La file d’attente — y a-t-il réellement quelque chose de cédulé, et est-ce available, auto-appliqué-après, ou forcé?
  • Votre fenêtre — RDS > Databases > votre-instance > Maintenance & backups montre le créneau actuel; vérifiez qu’il est vraiment hors pointe dans votre fuseau horaire, pas un aléa UTC.
  • AutoMinorVersionUpgrade — décidez délibérément si AWS peut redémarrer votre moteur à son horaire.
  • Le statut Multi-AZ — il détermine si la maintenance de classe redémarrage vous coûte un basculement ou une interruption complète.

Comment vérifier

# Quelle maintenance est en attente, et son urgence
aws rds describe-pending-maintenance-actions \
  --query 'PendingMaintenanceActions[].[ResourceIdentifier,
           PendingMaintenanceActionDetails[].[Action,AutoAppliedAfterDate,CurrentApplyDate,Description]]'

# Fenêtre actuelle et indicateur de mise à niveau automatique
aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[PreferredMaintenanceWindow,AutoMinorVersionUpgrade,MultiAZ,EngineVersion]'

Après toute fenêtre où quelque chose a tourné, le dossier est dans le journal d’événements :

aws rds describe-events --source-identifier prod-db --source-type db-instance \
  --duration 10080 --query 'Events[].[Date,Message]' --output table

Le runbook

  1. Définir la fenêtre exprès. aws rds modify-db-instance --db-instance-identifier prod-db --preferred-maintenance-window sun:07:00-sun:08:00 (les heures sont en UTC — convertissez; dimanche 07:00 UTC, c’est dimanche 03:00 à Montréal en été). Gardez-la à l’écart de la fenêtre de sauvegarde; les deux ne peuvent pas se chevaucher.
  2. Décider la politique de mise à niveau mineure automatique par palier. Posture de production raisonnable : activée en pré-production pour que les mises à niveau y trempent d’abord, désactivée en production, avec les mineures appliquées manuellement une semaine plus tard. Si vous la désactivez, le suivi des versions vous appartient — les mineures non rapiécées, c’est comme ça que des bases roulent des versions de moteur avec des CVE connues.
  3. Appliquer la maintenance en avance quand un élément apparaît dans la file, une nuit de votre choix : aws rds apply-pending-maintenance-action --resource-identifier arn:aws:rds:ca-central-1:123456789012:db:prod-db --apply-action system-update --opt-in-type immediate. immediate exécute maintenant; next-maintenance l’épingle à la fenêtre qui vient; undo-opt-in annule un opt-in de prochaine fenêtre.
  4. Lire la description de chaque action avant qu’elle tombe. Les détails disent si un redémarrage ou un basculement est attendu. Pour les actions de classe redémarrage en Multi-AZ, attendez-vous à un basculement : brève interruption d’écriture, repointage DNS, transactions en vol annulées — l’hygiène côté client de basculement inattendu s’applique mot pour mot.
  5. S’abonner aux événements de maintenance. Un abonnement aux événements RDS sur la catégorie maintenance, plus les notifications AWS Health à health.aws.amazon.com, et la maintenance cédulée devient un courriel deux semaines d’avance, pas une surprise en plein incident.
  6. Après la fenêtre, vérifier. Consultez le journal d’événements, la version du moteur et les taux d’erreurs applicatives pour la période de la fenêtre. Une action à moitié appliquée ou un saut de version qui brise une supposition du pilote doit être attrapé lundi matin par vous, pas jeudi par un client.

Quand c’est la mauvaise approche

Reporter la maintenance indéfiniment n’est pas une stratégie — les actions forced s’appliqueront à l’échéance, que ça vous convienne ou non, et les correctifs d’OS reportés accumulent du risque en silence. Si votre charge ne peut vraiment tolérer aucune fenêtre d’interruption régulière, la réponse n’est pas de combattre la fenêtre; c’est une architecture qui absorbe les basculements (Multi-AZ, lectures sur réplicas, logique de nouvelles tentatives) — une instance mono-AZ avec une exigence de « jamais de redémarrage » est une contradiction, et aucun réglage ne la résout. Le comportement complet de maintenance par moteur est dans la documentation Amazon RDS.

Erreurs fréquentes

  • Ne jamais définir la fenêtre et découvrir qu’elle tombe en pleines heures d’affaires seulement quand un redémarrage y atterrit.
  • Considérer la fenêtre comme « AWS redémarre ma base chaque semaine » — la plupart des fenêtres sont sans effet; c’est la file d’attente qui compte.
  • Laisser AutoMinorVersionUpgrade activé en production sans l’auditer, puis attribuer le redémarrage résultant à une panne.
  • Redémarrer pour un changement de paramètre statique pendant les heures d’affaires parce que « la maintenance redémarre déjà des choses de toute façon » — les paramètres statiques attendent votre redémarrage; cédulez-le comme de la maintenance.

Garder le contrôle

  • Passez describe-pending-maintenance-actions sur toute la flotte chaque semaine — un appel CLI, trente secondes.
  • Standardisez les fenêtres à l’échelle de la flotte dans un créneau hors pointe documenté, les fenêtres de pré-production une semaine avant la production.
  • Abonnements aux événements des catégories maintenance et failover vers le canal des opérations.
  • Suivez les versions mineures du moteur dans votre inventaire si la mise à niveau automatique est désactivée; les mineures périmées sont un passif silencieux.
  • Répétez la maintenance de classe redémarrage en pré-production d’abord — même action, même version de moteur, impact applicatif mesuré.

Les fenêtres de maintenance sont une des rares parties de RDS où vous choisissez quand la perturbation arrive — les équipes qui exercent ce choix cessent tout simplement d’avoir des incidents de maintenance. 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.