Aller au contenu

AWS Mis à jour le 2026-07-04

Déploiements bleu/vert RDS : mises à niveau de moteur et changements de schéma à risque quasi nul

Comment fonctionnent les déploiements bleu/vert RDS, ce que la bascule fait vraiment, et le runbook pour livrer des mises à niveau de moteur et des changements de schéma avec environ une minute d'interruption.

Un déploiement bleu/vert RDS crée une copie entièrement synchronisée de votre base de production (l’environnement vert), vous laisse mettre à niveau ou modifier la copie pendant que la production continue de servir le trafic, puis échange les deux dans une bascule qui se termine typiquement en moins d’une minute. Vos endpoints ne changent pas — RDS renomme les instances en dessous — donc les applications se reconnectent au nouvel environnement sans changement de configuration. C’est ce que RDS offre de plus proche d’une mise à niveau majeure sans drame.

Ce qui se passe

Quand vous créez un déploiement bleu/vert, RDS clone la topologie de l’environnement bleu (production) — primaire, réplicas, parameter groups — et garde le vert synchronisé par réplication : réplication binlog pour MySQL et MariaDB, réplication logique pour PostgreSQL, et les mêmes mécanismes sur les variantes Aurora. Le bleu/vert est disponible pour RDS MySQL, MariaDB et PostgreSQL, et pour Aurora MySQL et Aurora PostgreSQL — pas pour Oracle ni SQL Server.

Le vert est là où vous faites le travail risqué : une mise à niveau majeure du moteur, un changement de paramètre qui exige un redémarrage, un changement de classe d’instance, un changement de stockage, ou des changements de schéma comme l’ajout d’index. Parce que le vert est un réplica vivant du bleu, vous pouvez tester contre des données de production sans toucher à la production.

La bascule est la partie qui mérite d’être comprise. RDS exécute d’abord des garde-fous : il vérifie le retard de réplication, bloque les nouvelles écritures sur le bleu, attend que le vert rattrape complètement, puis renomme les environnements pour que les endpoints existants pointent vers le vert. Si les garde-fous ne peuvent pas terminer dans le délai de bascule que vous fixez (30 à 3 600 secondes, 300 par défaut), la bascule revient en arrière et le bleu continue de servir — ce mode d’échec est un inconvénient, pas une panne. Après une bascule réussie, les anciennes instances bleues survivent avec un suffixe -old1, avec les données au moment de la bascule, jusqu’à ce que vous les supprimiez.

Deux mises en garde honnêtes. Premièrement, sur PostgreSQL, la réplication logique ne transporte pas le DDL : les changements de schéma faits sur le bleu après la création du vert ne se propagent pas, donc vous gelez les changements de schéma pour la durée du déploiement. Deuxièmement, le vert est inscriptible — y écrire hors du changement prévu (la mise à niveau elle-même, la construction d’index) peut briser la réplication et invalider tout l’exercice. Les prérequis complets par moteur sont dans la documentation RDS sur https://docs.aws.amazon.com/rds/.

Quoi vérifier en premier

  • Admissibilité du moteur — MySQL, MariaDB, PostgreSQL, Aurora MySQL, Aurora PostgreSQL seulement, sur des versions supportées.
  • Prérequis de réplication logique PostgreSQL — rds.logical_replication = 1 sur la source, ce qui exige un redémarrage s’il n’est pas déjà activé, et les tables ont généralement besoin de clés primaires.
  • Consommateurs de réplication externes — les lecteurs binlog (Debezium, ETL) et les réplicas autogérés attachés au bleu ont besoin d’un plan pour la bascule.
  • Transactions longues — tout ce qui garde une transaction ouverte au moment de la bascule gruge le budget de délai.
  • Cache DNS dans l’application — le nom d’endpoint survit, mais les clients qui cachent les IP résolues au-delà du TTL se reconnecteront du mauvais côté.

Comment vérifier

Créez et inspectez un déploiement :

aws rds create-blue-green-deployment \
  --blue-green-deployment-name prod-pg16-upgrade \
  --source arn:aws:rds:ca-central-1:123456789012:db:prod-db \
  --target-engine-version 16.4 \
  --target-db-parameter-group-name prod-pg16-params

aws rds describe-blue-green-deployments \
  --query 'BlueGreenDeployments[].[BlueGreenDeploymentName,Status,SwitchoverDetails]'

Surveillez la santé de la réplication avant même de penser à basculer : dans la console, RDS > Databases montre les instances vertes imbriquées sous le déploiement bleu/vert, et l’onglet Monitoring du primaire vert expose ReplicaLag (MySQL) ou OldestReplicationSlotLag (PostgreSQL). Le retard devrait être en secondes et stable, pas en dents de scie.

aws cloudwatch get-metric-statistics --namespace AWS/RDS \
  --metric-name ReplicaLag \
  --dimensions Name=DBInstanceIdentifier,Value=prod-db-green-abc123 \
  --start-time 2026-07-04T12:00:00Z --end-time 2026-07-04T14:00:00Z \
  --period 300 --statistics Maximum

La marche à suivre

  1. Préparez d’abord la configuration cible. Parameter group de la nouvelle famille avec vos personnalisations portées, version de moteur cible, tout changement de classe d’instance. Le bleu/vert les applique à la création du vert, pas à la bascule.
  2. Créez le déploiement durant les heures creuses. La création initiale du vert copie l’ensemble des données; sur de grosses instances, ça prend des heures. La production n’est pas affectée, mais la charge de démarrage de la réplication est réelle.
  3. Validez le vert comme un environnement de staging. Connectez-vous directement aux endpoints verts (ils existent, avec des noms générés), lancez EXPLAIN sur vos pires requêtes, répétez les migrations, vérifiez les versions d’extensions. N’écrivez pas de données applicatives sur le vert.
  4. Gelez les changements de schéma et les gros travaux par lots. Sur PostgreSQL surtout, le DDL sur le bleu ne se réplique pas. Mettez en pause les pipelines de déploiement qui exécutent des migrations.
  5. Basculez avec un délai délibéré. aws rds switchover-blue-green-deployment --blue-green-deployment-identifier bgd-xxxx --switchover-timeout 300. Choisissez une fenêtre de faible trafic; la phase de blocage des écritures est là où les erreurs visibles arrivent, et elle dure habituellement bien moins d’une minute.
  6. Vérifiez, puis nettoyez. Confirmez la santé de l’application et que les écritures atterrissent sur le nouvel environnement, gardez les instances -old1 pour une période de grâce définie (c’est votre donnée de repli), puis supprimez le déploiement et les anciennes instances pour arrêter de les payer.

Quand c’est la mauvaise approche

Pour une montée mineure ou un ajustement de paramètre qui tolère un blip de fenêtre de maintenance, le bleu/vert est excessif — vous payez un environnement dupliqué complet pendant des jours. Il est aussi indisponible pour Oracle et SQL Server, et malcommode quand des consommateurs binlog externes ne tolèrent pas l’échange de topologie. Et il ne remplace pas une vraie conception haute disponibilité : la bascule est planifiée, le failover ne l’est pas, et le Multi-AZ garde le cas non planifié. Le retour en arrière après bascule n’est pas non plus un bouton — l’ancien bleu est une photo figée dans le temps, et les écritures arrivées sur le vert après la bascule n’existent que sur le vert.

Erreurs courantes

  • Écrire sur le vert avant la bascule et briser silencieusement la réplication — les garde-fous refusent alors de basculer et le déploiement doit être recréé.
  • Exécuter des migrations de schéma sur le bleu en cours de déploiement sur PostgreSQL, laissant le vert avec un schéma divergent.
  • Oublier le coût de stockage de l’environnement dupliqué — le vert est une copie complète d’instances et de stockage, facturée normalement pendant sa durée de vie.
  • Traiter l’ancien bleu comme un repli vivant des semaines plus tard, alors qu’il est figé au moment de la bascule et s’éloigne de la réalité chaque jour.

Prévention

  • Répétez le cycle complet une fois sur une base hors production pour que la première bascule en production ne soit pas la première bascule tout court.
  • Gardez les parameter groups et les versions cibles en infrastructure-as-code pour que la création du vert soit reproductible.
  • Mettez une alarme sur le retard de réplica de l’environnement vert durant la fenêtre de déploiement.
  • Bornez le déploiement dans le temps : créer, valider, basculer, nettoyer en moins d’une semaine, pour que le coût de l’environnement dupliqué reste une erreur d’arrondi.

Utilisé avec cette discipline, le bleu/vert transforme les opérations RDS les plus stressantes — les mises à niveau majeures du moteur avant tout — en une minute d’interruption contrôlée plutôt qu’une fenêtre de maintenance sans fin. 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.