Basculement d'un déploiement bleu/vert - Amazon Relational Database Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Basculement d'un déploiement bleu/vert

Une commutation favorise l'environnement vert pour en faire le nouvel environnement de production. Lorsque l'instance de base de données verte possède des réplicas en lecture, ils sont également promus. Avant le basculement, le trafic de production est routé vers l'instance de base de données et les réplicas en lecture dans l'environnement bleu. Après le basculement, le trafic de production est routé vers l'instance de base de données et les réplicas en lecture dans l'environnement vert.

Délai de commutation

Vous pouvez spécifier un délai de commutation compris entre 30 secondes et 3 600 secondes (une heure). Si la commutation prend plus de temps que la durée spécifiée, toutes les modifications sont annulées et aucune modification n'est apportée à l'un ou l'autre des environnements. Le délai d'attente par défaut est de 300 secondes (cinq minutes).

Barrières de protection de commutation

Lorsque vous lancez une commutation, Amazon RDS effectue quelques vérifications de base pour tester la préparation des environnements bleu et vert à la commutation. Ces contrôles sont connus sous le nom de barrières de protection de commutation. Ces barrières de protection empêchent une commutation si les environnements ne sont pas prêts pour cela. Ils évitent donc un temps d'arrêt plus long que prévu et empêchent la perte de données entre les environnements bleu et vert qui pourrait survenir si la commutation était lancée.

Amazon RDS exécute les contrôles de barrière de protection suivants sur l'environnement vert :

  • État de la réplication : vérifiez si l'état de réplication de l'instance de base de données principale verte est sain. L'instance de base de données principale verte est un réplica de l'instance de base de données principale bleue.

  • Décalage de réplication : vérifiez si le retard de réplica de l'instance de base de données principale verte se situe dans les limites autorisées pour la commutation. Les limites autorisées sont basées sur le délai d'attente spécifié. Le retard de réplica indique dans quelle mesure l'instance de base de données principale verte est en retard sur son instance de base de données principale bleue. Pour plus d'informations, consultez Diagnostic et résolution du retard entre réplicas en lecture pour RDS for MySQL et Surveillance et réglage du processus de réplication pour RDS for PostgreSQL.

  • Écritures actives : assurez-vous qu'aucune écriture n'est active sur l'instance de base de données principale verte.

Amazon RDS exécute les contrôles de barrière de protection suivants sur l'environnement bleu :

  • Réplication externe : pour RDS pour PostgreSQL, assurez-vous que l'environnement bleu n'est pas une source logique autogérée (éditeur) ou une réplique (abonné). Si tel est le cas, nous vous recommandons de supprimer les emplacements de réplication autogérés et les abonnements dans toutes les bases de données de l'environnement bleu, de procéder au basculement, puis de les recréer pour reprendre la réplication. Pour RDS for MySQL, assurez-vous que la base de données bleue n'est pas une réplique externe du journal binaire.

  • Écritures actives de longue durée : assurez-vous qu'il n'y a pas d'écritures actives de longue durée sur l'instance de base de données principale bleue, car elles peuvent augmenter le retard de réplica.

  • Instructions DDL de longue durée : assurez-vous qu'aucune instruction DDL de longue durée ne figure sur l'instance de base de données principale bleue, car elles peuvent augmenter le retard de réplica.

  • Modifications PostgreSQL non prises en charge : pour les instances de base de données RDS for PostgreSQL, assurez-vous qu'aucune modification DDL et qu'aucun ajout ou aucune modification d'objets volumineux n'ont été effectués dans l'environnement bleu. Pour plus d’informations, consultez Limitations de la réplication logique PostgreSQL pour les déploiements bleu/vert.

    Si Amazon RDS détecte des modifications PostgreSQL non prises en charge, il remplace l'état de réplication par Replication degraded et vous indique que la commutation n'est pas disponible pour le déploiement bleu/vert. Pour continuer la commutation, nous vous recommandons de supprimer et de recréer le déploiement bleu/vert ainsi que toutes les bases de données vertes. Pour ce faire, choisissez Actions, Supprimer avec les bases de données vertes.

Actions de commutation

Lorsque vous basculez un déploiement bleu/vert, RDS effectue les actions suivantes :

  1. Exécute des contrôles de barrière de protection pour vérifier si les environnements bleu et vert sont prêts pour la commutation.

  2. Arrête les nouvelles opérations d'écriture sur l'instance de base de données principale dans les deux environnements.

  3. Supprime les connexions aux instances de base de données dans les deux environnements et ne permet pas de nouvelles connexions.

  4. Attend que la réplication rattrape son retard dans l'environnement vert afin que celui-ci soit synchronisé avec l'environnement bleu.

  5. Renomme les instances de base de données dans les deux environnements.

    RDS renomme les instances de base de données dans l'environnement vert pour correspondre aux instances de base de données correspondantes dans l'environnement bleu. Par exemple, supposons que le nom d'une instance de base de données dans l'environnement bleu est mydb. Supposons également que le nom de l'instance de base de données correspondante dans l'environnement vert est mydb-green-abc123. Pendant la commutation, le nom de l'instance de base de données dans l'environnement vert devient mydb.

    RDS renomme les instances de base de données dans l'environnement bleu en ajoutant -oldn au nom actuel, où n est un nombre. Par exemple, supposons que le nom d'une instance de base de données dans l'environnement bleu est mydb. Après la commutation, le nom de l'instance de base de données pourrait être mydb-old1.

    RDS renomme également les points de terminaison dans l'environnement vert pour qu'ils correspondent aux points de terminaison correspondants dans l'environnement bleu, de sorte que les changements d'application ne sont pas nécessaires.

  6. Permet les connexions aux bases de données dans les deux environnements.

  7. Autorise les opérations d'écriture sur le cluster de base de données dans le nouvel environnement de production.

    Après le basculement, le précédent de base de données principale de production autorise les opérations de lecture uniquement jusqu'à son redémarrage.

Vous pouvez surveiller l'état d'un passage au numérique à l'aide d'Amazon. EventBridge Pour plus d’informations, consultez Événements de déploiement bleu/vert.

Si vous avez des étiquettes configurées dans l'environnement bleu, ces étiquettes sont déplacées vers le nouvel environnement de production lors de la commutation. L'environnement de production précédent conserve également ces étiquettes. Pour en savoir plus sur les identifications, consultez Balisage de ressources Amazon RDS.

Si la commutation commence et s'arrête avant la fin pour une raison quelconque, les modifications sont annulées et aucune modification n'est apportée à l'environnement.

Bonnes pratiques de commutation

Avant de basculer, nous vous recommandons vivement de respecter les bonnes pratiques en accomplissant les tâches suivantes :

  • Testez minutieusement les ressources dans l'environnement vert. Assurez-vous qu'elles fonctionnent correctement et efficacement.

  • Surveillez les CloudWatch statistiques Amazon pertinentes. Pour plus d’informations, consultez Vérification des CloudWatch métriques avant le passage au numérique.

  • Déterminez le meilleur moment pour la commutation.

    Pendant la commutation, les écritures sont interrompues dans les bases de données des deux environnements. Identifiez un moment où le trafic est le plus faible dans votre environnement de production. Les transactions de longue durée, telles que les DDL actives, peuvent augmenter le temps de commutation, ce qui entraîne des temps d'arrêt plus longs pour vos charges de travail de production.

    S'il existe un grand nombre de connexions sur vos instances de base de données, pensez à les réduire manuellement au minimum nécessaire pour votre application avant de basculer vers le déploiement bleu/vert. Une manière de procéder consiste à créer un script qui surveille le statut du déploiement bleu/vert et qui commence à nettoyer les connexions lorsqu'il détecte que le statut est passé à SWITCHOVER_IN_PROGRESS.

  • Assurez-vous que les instances de base de données dans les deux environnements sont dans l'état Available.

  • Assurez-vous que l'instance de base de données principale dans l'environnement vert est dans un état sain et qu'il se réplique.

  • Veillez à ce que les configurations de votre réseau et de votre client n'augmentent pas la durée de vie (TTL) du cache DNS au-delà de cinq secondes, ce qui est la valeur par défaut pour les zones DNS RDS.
 Sinon, les applications continueront à envoyer du trafic d'écriture vers l'environnement bleu après la commutation.

  • Vous ne pouvez pas annuler un déploiement bleu/vert après le passage au numérique. Pour les charges de travail de production critiques, pensez à provisionner un de sauvegarde avant de passer au relais.

  • Assurez-vous que le chargement des données est terminé avant de basculer. Pour plus d’informations, consultez Gestion du chargement différé lorsque vous créez un déploiement bleu/vert.

  • Pour les de base de données PostgreSQL, procédez comme suit :

Note

Lors d'une commutation, vous ne pouvez modifier aucune instance de base de données incluse dans la commutation.

Vérification des CloudWatch métriques avant le passage au numérique

Avant de passer à un déploiement bleu/vert, nous vous recommandons de vérifier les valeurs des métriques suivantes sur Amazon. CloudWatch

  • ReplicaLag : utilisez cette métrique pour identifier le retard de réplication actuel dans l'environnement vert. Pour réduire les temps d'arrêt, veillez à ce que cette valeur soit proche de zéro avant d'effectuer le basculement.

  • DatabaseConnections : utilisez cette métrique pour estimer le niveau d'activité du déploiement bleu/vert et assurez-vous que la valeur est à un niveau acceptable pour votre déploiement avant d'effectuer le basculement. Si l'analyse des performances est activée, DBLoad est une métrique plus précise.

Pour plus d'informations sur ces métriques, consultez CloudWatch Métriques Amazon pour Amazon RDS.

Basculement d'un déploiement bleu/vert

Vous pouvez passer d'un déploiement bleu/vert à l'aide de l'API AWS Management Console, de AWS CLI, ou de l'API RDS.

Pour effectuer un basculement de déploiement bleu/vert
  1. Connectez-vous à la console Amazon RDS AWS Management Console et ouvrez-la à l'adresse https://console.aws.amazon.com/rds/.

  2. Dans le panneau de navigation, choisissez Bases de données, puis sélectionnez le déploiement bleu/vert que vous souhaitez basculer.

  3. Pour Actions, choisissez Basculer.

    La page Basculer apparaît.

    
                  Basculement du déploiement bleu/vert
  4. Sur la page Basculer, consultez le résumé de la commutation. Assurez-vous que les ressources des deux environnements correspondent à ce que vous attendez. Si ce n'est pas le cas, choisissez Annuler.

  5. Dans le champ Paramètre de délai d'attente, entrez le délai limite pour la commutation.

  6. Si votre instance exécute RDS for PostgreSQL, passez en revue et confirmez les recommandations avant la commutation. Pour plus d’informations, consultez Limitations de la réplication logique PostgreSQL pour les déploiements bleu/vert.

  7. Choisissez Basculer.

Pour passer d'un déploiement bleu/vert à l'aide de AWS CLI, utilisez la switchover-blue-green-deploymentcommande avec les options suivantes :

  • --blue-green-deployment-identifier— Spécifiez l'ID de ressource du déploiement bleu/vert.

  • --switchover-timeout : spécifiez la limite de temps pour la commutation, en secondes. La valeur par défaut est 300.

Exemple Basculement d'un déploiement bleu/vert

Pour LinuxmacOS, ou Unix :

aws rds switchover-blue-green-deployment \ --blue-green-deployment-identifier bgd-1234567890abcdef \ --switchover-timeout 600

Dans Windows :

aws rds switchover-blue-green-deployment ^ --blue-green-deployment-identifier bgd-1234567890abcdef ^ --switchover-timeout 600

Pour basculer un déploiement bleu/vert en utilisant l'API Amazon RDS, utilisez l'opération SwitchoverBlueGreenDeployment avec les paramètres suivants :

  • BlueGreenDeploymentIdentifier— Spécifiez l'ID de ressource du déploiement bleu/vert.

  • SwitchoverTimeout : spécifiez la limite de temps pour la commutation, en secondes. La valeur par défaut est 300.

Après la commutation

Après une commutation, les instances de base de données de l'environnement bleu précédent sont conservé(e)s. Les coûts standard s'appliquent à ces ressources. La réplication entre les environnements bleu et vert s'arrête.

RDS renomme les instances de base de données dans l'environnement bleu en ajoutant -oldn au nom de la ressource actuelle, où n est un nombre. Les instances de base de données sont en lecture seule jusqu'à ce que vous définissiez le paramètre read_only sur 0.


          Après le passage d'un déploiement bleu/vert

Mise à jour du nœud parent pour les consommateurs

Après avoir basculé vers un déploiement RDS pour MariaDB ou RDS pour MySQL MySQL de base de données contenait des répliques externes ou des consommateurs de journaux binaires avant le basculement, vous devez mettre à jour son nœud parent après le basculement afin de maintenir la continuité de la réplication.

Après le basculement, l'instance de base de données du qui se trouvait auparavant dans l'environnement vert émet un événement contenant le nom du fichier journal principal et la position du journal principal. Par exemple :

aws rds describe-events --output json --source-type db-instance --source-identifier db-instance-identifier { "Events": [ ... { "SourceIdentifier": "db-instance-identifier", "SourceType": "db-instance", "Message": "Binary log coordinates in green environment after switchover: file mysql-bin-changelog.000003 and position 804", "EventCategories": [], "Date": "2023-11-10T01:33:41.911Z", "SourceArn": "arn:aws:rds:us-east-1:123456789012:db:db-instance-identifier" } ] }

Tout d'abord, assurez-vous que le consommateur ou la réplique a appliqué tous les journaux binaires de l'ancien environnement bleu. Ensuite, utilisez les coordonnées binaires du journal fournies pour reprendre l'application auprès des consommateurs. Par exemple, si vous exécutez une réplique MySQL sur EC2, vous pouvez utiliser la CHANGE MASTER TO commande suivante :

CHANGE MASTER TO MASTER_HOST='{new-writer-endpoint}', MASTER_LOG_FILE='mysql-bin-changelog.000003', MASTER_LOG_POS=804;
Note

Si le consommateur est une autre instance de base de données RDS pour MariaDB ou RDS pour MariaDB, vous pouvez exécuter les procédures stockées suivantes dans l'ordre :,, et. mysql.rds_stop_replication mysql.rds_reset_external_master mysql.rds_set_external_master mysql.rds_start_replication