Aller au contenu

AWS Mis à jour le 2026-07-04

Mises à niveau de version RDS : mineure vs majeure, et comment répéter les majeures

En quoi les mises à niveau mineures et majeures du moteur RDS diffèrent, ce qui cause vraiment l'indisponibilité, et un runbook de répétition qui rend une mise à niveau majeure ennuyante plutôt que terrifiante.

Les mises à niveau mineures de RDS restent dans la même famille de version majeure, cassent rarement les applications et peuvent être automatisées dans la fenêtre de maintenance sans danger. Les mises à niveau majeures changent le comportement du moteur — sémantique SQL, valeurs par défaut, planificateur de requêtes — et la seule façon d’en rendre une sécuritaire est de la répéter d’abord sur une copie restaurée de la production. La mise à niveau elle-même est un appel d’API; le travail, c’est tout ce que vous faites avant.

Ce qui se passe

Une mise à niveau mineure (PostgreSQL 16.3 vers 16.4, MySQL 8.0.36 vers 8.0.37) livre des correctifs de bogues et des correctifs CVE avec une promesse de compatibilité. Si AutoMinorVersionUpgrade est activé, RDS l’applique durant une fenêtre de maintenance une fois qu’AWS a désigné cette version pour la mise à niveau automatique. Attendez-vous quand même à une courte interruption : sur un déploiement Multi-AZ de type instance, RDS met à niveau le primaire et le standby ensemble pour les changements de moteur, donc le Multi-AZ ne masque pas l’indisponibilité comme il le fait pour une panne matérielle. Les clusters Multi-AZ (la topologie à deux standbys lisibles) peuvent faire des mises à niveau mineures en mode roulant avec une interruption beaucoup plus courte.

Une mise à niveau majeure (PostgreSQL 15 vers 16, MySQL 5.7 vers 8.0) n’est jamais automatique. Vous la déclenchez, RDS exécute des prévérifications du moteur, prend un snapshot avant et après, et convertit le dictionnaire de données — pg_upgrade sous le capot pour PostgreSQL. Trois choses surprennent régulièrement les équipes : l’instance a besoin d’un parameter group de la nouvelle famille, donc vos paramètres ajustés doivent être portés, pas transférés; les statistiques de l’optimiseur PostgreSQL ne sont pas migrées, donc les requêtes tournent mal jusqu’à ce que vous lanciez ANALYZE; et la gestion des réplicas en lecture diffère selon le moteur — RDS pour PostgreSQL met à niveau les réplicas avec le primaire, tandis que pour MySQL vous mettez à niveau les réplicas vous-même, normalement avant le primaire.

Il y a aussi une horloge qui tourne. Quand une version de moteur atteint la fin de vie communautaire, RDS la déplace vers l’Extended Support et la facture par vCPU-heure — rester sur une vieille version n’est plus gratuit. Le calendrier des versions vit dans les notes de version du moteur sur https://docs.aws.amazon.com/rds/.

Quoi vérifier en premier

  • Version actuelle et indicateur d’auto-upgrade — sachez exactement ce que vous exécutez et si AWS va le déplacer sans vous.
  • Cibles de mise à niveau valides — vous ne pouvez souvent pas sauter directement à la dernière majeure; RDS définit des chemins permis.
  • Parameter group — personnalisé ou par défaut? Personnalisé signifie que vous avez un diff à porter vers la nouvelle famille. Voir l’ajustement des parameter groups pour Postgres / MySQL en production.
  • Réplicas en lecture — combien, quelles versions, et quelles règles de moteur s’y appliquent.
  • Maintenance en attente — une action OS ou certificat déjà planifiée peut entrer en collision avec votre fenêtre.

Comment vérifier

aws rds describe-db-instances --db-instance-identifier prod-db \
  --query 'DBInstances[0].[EngineVersion,AutoMinorVersionUpgrade,DBParameterGroups[0].DBParameterGroupName,ReadReplicaDBInstanceIdentifiers]'

aws rds describe-db-engine-versions --engine postgres --engine-version 15.8 \
  --query 'DBEngineVersions[0].ValidUpgradeTarget[].{Version:EngineVersion,Major:IsMajorVersionUpgrade}' \
  --output table

aws rds describe-pending-maintenance-actions

Dans la console, RDS > Databases > (instance) > Maintenance & backups montre la fenêtre de maintenance et les actions en attente. Après une mise à niveau de répétition, l’onglet Logs & events montre les échecs de prévérification — pour MySQL 5.7 vers 8.0, ils atterrissent dans un journal de mise à niveau que vous pouvez lire directement là.

La marche à suivre

  1. Restaurez une copie de répétition. Restaurez le dernier snapshot (ou une restauration à un instant précis) dans une nouvelle instance dans un compte ou VPC hors production, même classe d’instance et même stockage que la production. Une base de test vide ne prouve rien — la durée de mise à niveau et les échecs de prévérification varient avec les vraies données.
  2. Exécutez la mise à niveau sur la copie et chronométrez-la. aws rds modify-db-instance --db-instance-identifier rehearsal-db --engine-version 16.4 --allow-major-version-upgrade --apply-immediately. Notez l’indisponibilité réelle; ce chiffre est ce que vous annoncez à l’entreprise.
  3. Corrigez ce que les prévérifications trouvent. Tables orphelines, versions d’extensions non supportées, collisions de mots réservés (MySQL 8.0 a réservé rank et groups), paramètres incompatibles. Corrigez en production avant la vraie exécution pour que la prévérification passe sans accroc.
  4. Portez le parameter group. Créez un parameter group dans la nouvelle famille, comparez vos personnalisations aux nouvelles valeurs par défaut — certains paramètres changent de sens ou disparaissent entre les majeures — et attachez-le dans le cadre de la mise à niveau.
  5. Testez l’application contre la copie. Pointez une application de staging vers l’instance de répétition et exécutez vos flux clés, pas juste SELECT 1. Les changements du planificateur apparaissent ici, nulle part ailleurs.
  6. Planifiez la vraie exécution. Prenez un snapshot manuel juste avant (RDS prend le sien, mais le vôtre suit vos règles de rétention). Pour MySQL, mettez à niveau les réplicas d’abord; pour PostgreSQL, attendez-vous à ce que les réplicas suivent le primaire.
  7. Tâches post-mise à niveau immédiates. Sur PostgreSQL, lancez ANALYZE sur chaque base, puis mettez à jour les extensions avec ALTER EXTENSION ... UPDATE. Surveillez la latence p95 et le CPU pendant 48 heures contre votre référence pré-mise à niveau.

Quand c’est la mauvaise approche

Si l’entreprise ne peut pas absorber l’indisponibilité mesurée à l’étape 2 — pour de grosses instances occupées, une mise à niveau majeure peut dépasser largement une heure — la mise à niveau sur place est le mauvais outil. Utilisez plutôt un déploiement bleu/vert RDS : la mise à niveau se fait sur une copie synchronisée et la bascule prend environ une minute. Et si le motif est seulement un CVE, vérifiez si une version mineure de votre famille actuelle porte déjà le correctif avant de planifier une majeure.

Erreurs courantes

  • Supposer que Multi-AZ signifie mises à niveau sans interruption. Les mises à niveau de moteur sur les déploiements Multi-AZ de type instance prennent les deux nœuds en même temps.
  • Sauter ANALYZE après une majeure PostgreSQL, puis passer une journée à chasser une « base lente » qui n’a simplement pas de statistiques.
  • Laisser l’instance sur le parameter group par défaut de la nouvelle famille, perdant silencieusement des années d’ajustement.
  • Répéter sur un petit jeu de données synthétique, de sorte que l’exécution en production prend cinq fois plus longtemps que promis.

Prévention

  • Gardez AutoMinorVersionUpgrade activé pour tout sauf les charges les plus sensibles au changement, et connaissez votre fenêtre de maintenance.
  • Suivez les dates de fin de vie des moteurs chaque année; les frais d’Extended Support transforment la procrastination en ligne budgétaire.
  • Gardez les parameter groups en infrastructure-as-code pour que le portage vers une nouvelle famille soit un diff révisé, pas de l’archéologie.
  • Répétez une mise à niveau majeure par année même si aucune n’est due — le réflexe compte plus que la version.
  • Si une mise à niveau tourne mal en production, ouvrez un dossier tôt; le support AWS voit un état côté moteur que vous ne voyez pas.

Une mise à niveau majeure menée ainsi est un non-événement planifié : les prévérifications passent parce que vous les avez déjà corrigées, l’indisponibilité correspond à la répétition, et l’application a été testée contre le nouveau planificateur des semaines d’avance. 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.