Présentation des déploiements bleu/vert Amazon RDS

En utilisant les déploiements bleu/vert Amazon RDS, vous pouvez apporter et tester des modifications de base de données avant de les implémenter dans un environnement de production. Un déploiement bleu/vert crée un environnement intermédiaire qui copie l'environnement de production. Dans un déploiement bleu/vert, l'environnement bleu est l'environnement de production actuel. L'environnement vert est l'environnement intermédiaire. L'environnement intermédiaire reste synchronisé avec l'environnement de production actuel grâce à la réplication logique.

Vous pouvez apporter des modifications aux instances de base de données RDS dans l'environnement vert sans affecter les charges de travail de production. Par exemple, vous pouvez mettre à niveau la version majeure ou mineure du moteur de base de données, mettre à niveau la configuration du système de fichiers sous-jacent, ou modifier les paramètres de la base de données dans l'environnement intermédiaire. Vous pouvez tester en profondeur les changements dans l'environnement vert. Lorsque vous êtes prêt, vous pouvez basculer les environnements pour promouvoir l'environnement vert comme nouvel environnement de production. La commutation prend généralement moins d'une minute, sans perte de données et sans qu'il soit nécessaire de modifier les applications.

Comme l'environnement vert est une copie de la topologie de l'environnement de production, il inclut les fonctionnalités utilisées par l'instance de base de données. Ces fonctionnalités comprennent les réplicas en lecture, la configuration du stockage, les instantanés de base de données, les sauvegardes automatiques, Performance Insights et la surveillance améliorée. Si l'instance de base de données bleue est un déploiement d'instance de base de données multi-AZ, alors l'instance de base de données verte est également un déploiement d'instance de base de données multi-AZ.

Note

Actuellement, les déploiements bleu/vert ne sont pris en charge que par RDS for MariaDB, RDS for MySQL et RDS for PostgreSQL. Pour connaître la disponibilité d'Amazon Aurora, consultez la section Utilisation des déploiements Amazon RDS Blue/Green pour les mises à jour des bases de données dans le guide de l'utilisateur Amazon Aurora.

Disponibilité des régions et des versions

La disponibilité et la prise en charge des fonctionnalités varient selon les versions spécifiques de chaque moteur de base de données, et selon les Régions AWS. Pour plus d’informations, consultez Régions et moteurs de base de données pris en charge pour les déploiements Amazon RDS Blue/Green.

Avantages de l'utilisation des déploiements bleu/vert Amazon RDS

En utilisant les déploiements bleu/vert Amazon RDS, vous pouvez rester à jour sur les correctifs de sécurité, améliorer les performances de base de données et adopter de nouvelles fonctionnalités de base de données avec des temps d'arrêt courts et prévisibles. Les déploiements bleu/vert réduisent les risques et les temps d'arrêt pour les mises à jour de base de données, comme les mises à niveau majeures ou mineures des versions du moteur.

Les déploiements bleu/vert offrent les avantages suivants :

• Créez facilement un environnement intermédiaire prêt pour la production.

• Répliquez automatiquement les modifications apportées aux bases de données de l'environnement de production à l'environnement intermédiaire.

• Testez les modifications apportées aux bases de données dans un environnement intermédiaire sûr sans affecter l'environnement de production.

• Restez à jour des correctifs de base de données et des mises à jour du système.

• Mettez en œuvre et testez les nouvelles fonctionnalités de base de données.

• Basculez votre environnement intermédiaire pour en faire le nouvel environnement de production sans modifier votre application.

• Basculez en toute sécurité grâce aux barrières de protection de commutation intégrées.

• Éliminez les pertes de données pendant la commutation.

• Basculez rapidement, généralement en moins d'une minute en fonction de votre charge de travail.

Flux de travail d'un déploiement bleu/vert

Effectuez les principales étapes suivantes lorsque vous utilisez un déploiement bleu/vert pour les mises à jour de base de données.

1. Identifiez un environnement de production qui nécessite des mises à jour.

   Par exemple, l'environnement de production dans cette image comporte un déploiement d'instance de base de données multi-AZ (mydb1) et un réplica en lecture (mydb2).

   

2. Créez le déploiement bleu/vert. Pour obtenir des instructions, veuillez consulter Création d'un déploiement bleu/vert.

   L'image suivante montre un exemple de déploiement bleu/vert de l'environnement de production de l'étape 1. Lors de la création du déploiement bleu/vert, RDS copie la topologie et la configuration complètes de l'instance de base de données principale pour créer l'environnement vert. Les noms des instances de base de données copiées sont complétés par -green-random-characters. L'environnement intermédiaire de l'image contient le déploiement d'une instance de base de données multi-AZ (mydb1-green-abc123) et un réplica en lecture (mydb2-green-abc123).

   

   Lorsque vous créez le déploiement bleu/vert, vous pouvez mettre à niveau la version de votre moteur de base de données et spécifier un groupe de paramètres de base de données différent pour les instances de base de données dans l'environnement vert. RDS configure également la réplication logique de l'instance de base de données principale dans l'environnement bleu vers l'instance de base de données principale dans l'environnement vert.

   Après avoir créé le déploiement bleu/vert, l'instance de base de données dans l'environnement vert est en lecture seule par défaut.

3. Apportez des modifications supplémentaires à l'environnement intermédiaire, si nécessaire.

   Par exemple, vous pouvez apporter des modifications au schéma de votre base de données ou changer la classe d'instances de base de données utilisée par une ou plusieurs instances de base de données dans l'environnement vert.

   Pour savoir comment modifier une instance de base de données, consultez Modification d'une instance de base de données Amazon RDS.

4. Testez votre environnement intermédiaire.

   Pendant les tests, nous vous recommandons de garder vos bases de données dans l'environnement vert en lecture seule. Activez les opérations d'écriture dans un environnement vert avec prudence, car elles peuvent entraîner des conflits de réplication. Elles peuvent également entraîner la présence de données involontaires dans les bases de données de production après la commutation. Pour activer les opérations d'écriture pour RDS pour MySQL, définissez le read_only paramètre sur0, puis redémarrez l'instance de base de données. Pour RDS pour PostgreSQL, définissez le paramètre sur default_transaction_read_only au niveau de la sessionoff.

5. Une fois prêt, basculez pour promouvoir l'environnement intermédiaire en tant que nouvel environnement de production. Pour obtenir des instructions, veuillez consulter Basculement d'un déploiement bleu/vert.

   La commutation entraîne un temps d'arrêt. Le temps d'arrêt est généralement inférieur à une minute, mais il peut être plus long en fonction de votre charge de travail.

   L'image suivante présente les instances de base de données après la commutation.

   

   Après la commutation, les instances de base de données qui se trouvaient dans l'environnement vert deviennent les nouvelles instances de base de données de production. Les noms et les points de terminaison de l'environnement de production actuel sont affectés à l'environnement de production nouvellement promu, ce qui ne nécessite aucune modification de votre application. En conséquence, votre trafic de production s'écoule désormais vers le nouvel environnement de production. Les instances de base de données dans l'environnement bleu précédent sont renommées en ajoutant -oldn au nom actuel, où n est un numéro. Par exemple, supposons que le nom de l'instance de base de données dans l'environnement bleu est mydb1. Après la commutation, le nom de l'instance de base de données pourrait être mydb1-old1.

   Dans l'exemple de l'image, les changements suivants se produisent pendant la commutation :

   • Le déploiement de l'instance de base de données multi-AZ de l'environnement vert nommé mydb1-green-abc123 devient le déploiement de l'instance de base de données multi-AZ de production nommé mydb1.

   • Le réplica en lecture nommé mydb2-green-abc123 de l'environnement vert devient le réplica en lecture mydb2 de l'environnement de production.

   • Le déploiement de l'instance de base de données multi-AZ nommée mydb1 de l'environnement bleu devient mydb1-old1.

   • Le réplica en lecture nommé mydb2 de l'environnement bleu devient mydb2-old1.

6. Si vous n'avez plus besoin d'un déploiement bleu/vert, vous pouvez le supprimer. Pour obtenir des instructions, veuillez consulter Suppression d'un déploiement bleu/vert.

   Après la commutation, l'environnement de production précédent n'est pas supprimé afin que vous puissiez l'utiliser pour les tests de régression, si nécessaire.

Autorisation de l'accès aux opérations de déploiement bleu/vert

Les utilisateurs doivent disposer des autorisations requises pour effectuer les opérations liées aux déploiements bleu/vert. Vous pouvez créer des politiques IAM qui accordent aux utilisateurs et aux rôles l'autorisation d'effectuer des opérations d'API spécifiques sur les ressources spécifiées dont ils ont besoin. Vous pouvez ensuite attacher ces politiques aux jeux d'autorisations ou rôles IAM qui requièrent ces autorisations. Pour plus d’informations, consultez Identity and Access Management pour Amazon RDS.

L'utilisateur qui crée un déploiement bleu/vert doit avoir les autorisations nécessaires pour effectuer les opérations RDS suivantes :

• rds:AddTagsToResource

• rds:CreateDBInstanceReadReplica

L'utilisateur qui bascule un déploiement bleu/vert doit avoir les autorisations nécessaires pour effectuer les opérations RDS suivantes :

• rds:ModifyDBInstance

• rds:PromoteReadReplica

L'utilisateur qui supprime un déploiement bleu/vert doit avoir les autorisations nécessaires pour effectuer une ou plusieurs opérations RDS suivantes :

• rds:DeleteDBInstance

Amazon RDS met en service et modifie les ressources dans l'environnement intermédiaire en votre nom. Ces ressources incluent des instances de base de données qui utilisent une convention de dénomination définie en interne. Par conséquent, les politiques IAM jointes ne peuvent pas contenir de modèles de noms de ressources partiels tels quemy-db-prefix-*. Seuls les caractères génériques (*) sont pris en charge. En général, nous recommandons d'utiliser des balises de ressources et d'autres attributs pris en charge pour contrôler l'accès à ces ressources, plutôt que des caractères génériques. Pour plus d'informations, consultez Actions, ressources et clés de condition pour Amazon RDS.

Considérations relatives aux déploiements bleu/vert

Amazon RDS effectue le suivi des ressources dans les déploiements bleu/vert avec le DbiResourceId de chaque ressource. Cet identifiant de ressource est un identifiant Région AWS unique et immuable pour la ressource.

L'ID de ressource est distinct de l'ID d'instance de base de données :

Le nom d'une ressource (ID d'instance) change lorsque vous passez à un déploiement bleu/vert, mais chaque ressource conserve le même ID de ressource. Par exemple, l'identifiant d'une instance de base de données peut être mydb dans l'environnement bleu. Après la commutation, la même instance de base de données peut être renommée en mydb-old1. Cependant, l'ID de ressource de l'instance de base de données ne change pas pendant la commutation. Ainsi, lorsque les ressources vertes sont promues en tant que nouvelles ressources de production, leurs identifiants ne correspondent pas aux identifiants des ressources bleues qui étaient précédemment en production.

Après avoir basculé un déploiement bleu/vert, pensez à mettre à jour les ID de ressources pour qu'ils correspondent à ceux des ressources de production nouvellement promues pour les fonctionnalités et services intégrés que vous avez utilisés avec les ressources de production. Plus précisément, envisagez les mises à jour suivantes :

• Si vous effectuez un filtrage à l'aide de l'API RDS et des identifiants de ressources, ajustez les identifiants de ressources utilisés dans le filtrage après la commutation.

• Si vous l'utilisez CloudTrail pour auditer des ressources, ajustez les consommateurs de CloudTrail afin de suivre les nouveaux identifiants de ressources après le passage au numérique. Pour plus d’informations, consultez Surveillance des appels d'API Amazon RDS dansAWS CloudTrail.

• Si vous utilisez l'API Performance Insights, ajustez les ID des ressources dans les appels à l'API après la commutation. Pour plus d’informations, consultez Surveillance de la charge de la base de données avec Performance Insights sur Amazon RDS.

  Vous pouvez surveiller une base de données avec le même nom après la commutation, mais elle ne contient pas les données d'avant la commutation.

• Si vous utilisez des identifiants de ressources dans les politiques IAM, veillez à ajouter les identifiants des ressources nouvellement promues lorsque cela est nécessaire. Pour plus d’informations, consultez Identity and Access Management pour Amazon RDS.

• Si des rôles IAM sont associés à votre instance de base de données de de base de données, veillez à les réassocier après le passage au numérique. Les rôles attachés ne sont pas automatiquement copiés dans l'environnement vert.

• Si vous vous authentifiez auprès de votre instance de base de données à l'aide de l'authentification de base de données IAM, veillez à ce que la politique IAM utilisée pour accéder à la base de données contienne à la fois les bases de données bleues et vertes répertoriées sous l'élément Resource de la politique. Cela est nécessaire pour se connecter à la base de données verte après la commutation. Pour plus d’informations, consultez Création et utilisation d'une politique IAM pour l'accès à une base de données IAM.

• Si vous avez l'habitude AWS Backup de gérer des sauvegardes automatisées des ressources dans un déploiement bleu/vert, ajustez les identifiants de ressources utilisés AWS Backup après le passage au numérique. Pour plus d’informations, consultez Utilisation AWS Backup pour gérer les sauvegardes automatisées.

• Si vous souhaitez restaurer un instantané de base de données manuel ou automatisé pour une instance de base de données qui faisait partie d'un déploiement bleu/vert, assurez-vous de restaurer le bon instantané de base de données en examinant l'heure à laquelle l'instantané a été pris. Pour plus d’informations, consultez Restauration vers une instance de base de données.

• Si vous voulez décrire une sauvegarde automatisée de l'instance de base de données précédente de l'environnement bleu ou la restaurer à un moment donné, utilisez l'ID de ressource pour l'opération.

  Comme le nom de l'instance de base de données change pendant la commutation, vous ne pouvez pas utiliser son nom précédent pour les opérations DescribeDBInstanceAutomatedBackups ou RestoreDBInstanceToPointInTime.

  Pour plus d’informations, consultez Restauration d'une instance de base de données à une date spécifiée.

• Lorsque vous ajoutez un réplica en lecture à une instance de base de données dans l'environnement vert d'un déploiement bleu/vert, le nouveau réplica en lecture ne remplacera pas un réplica en lecture dans l'environnement bleu lors du basculement. Cependant, le nouveau réplica en lecture est conservé dans le nouvel environnement de production après la commutation.

• Lorsque vous supprimez une instance de base de données dans l'environnement vert d'un déploiement bleu/vert, vous ne pouvez pas créer une nouvelle instance de base de données pour la remplacer dans le déploiement bleu/vert.

  Si vous créez une nouvelle instance de base de données avec le même nom et le même Amazon Resource Name (ARN) que l'instance de base de données supprimée, elle a une valeur DbiResourceId différente, de sorte qu'elle ne fait pas partie de l'environnement vert.

  Le comportement suivant survient si vous supprimez une instance de base de données dans l'environnement vert :

  • Si l'instance de base de données dans l'environnement bleu avec le même nom existe, elle ne sera pas basculée vers l'instance de base de données dans l'environnement vert. Cette instance de base de données ne sera pas renommée en ajoutant -oldn au nom de l'instance de base de données.

  • Toute application qui pointe vers l'instance de base de données dans l'environnement bleu continue à utiliser la même instance de base de données après la commutation.

  Le même comportement s'applique aux instances de base de données et aux réplicas en lecture.

Bonnes pratiques pour les déploiements bleu/vert

Voici les bonnes pratiques pour les déploiements bleus/verts :

Bonnes pratiques d'ordre général

• Testez minutieusement les instances de base de données dans l'environnement vert avant le basculement.

• Gardez vos bases de données dans l'environnement vert en lecture seule. Nous vous recommandons d'activer les opérations d'écriture sur l'environnement vert avec prudence, car elles peuvent entraîner des conflits de réplication. Elles peuvent également entraîner la présence de données involontaires dans les bases de données de production après la commutation.

• Lorsque vous utilisez un déploiement bleu/vert pour la mise en œuvre de modifications de schémas, n'effectuez que des modifications compatibles avec la réplication.

  Par exemple, vous pouvez ajouter de nouvelles colonnes à la fin d'un tableau sans perturber la réplication entre le déploiement bleu et le déploiement vert. Toutefois, les modifications de schéma, telles que le renommage de colonnes ou de tables, interrompent la réplication vers le déploiement vert.

  Pour plus d'informations sur les modifications compatibles avec la réplication, consultez Replication with Differing Table Definitions on Source and Replica dans la documentation MySQL, et Restrictions dans la documentation Réplication logique PostgreSQL.

• Après avoir créé le déploiement bleu/vert, gérez le chargement différé si nécessaire. 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.

• Lorsque vous basculez vers un déploiement bleu/vert, suivez les bonnes pratiques de commutation. Pour plus d’informations, consultez Bonnes pratiques de commutation.

Bonnes pratiques pour RDS for MySQL

• Évitez d'utiliser des moteurs de stockage non transactionnels, tels que MyISAM, qui ne sont pas optimisés pour la réplication.

• Optimisez les réplicas en lecture pour la réplication des journaux binaires.

  Par exemple, si la version de votre moteur de base de données le permet, envisagez d'utiliser la réplication GTID, la réplication parallèle et la réplication à sécurité intégrée dans votre environnement de production avant de procéder à votre déploiement bleu/vert. Ces options favorisent la cohérence et la pérennité de vos données avant de basculer votre déploiement bleu/vert. Pour plus d'informations sur la réplication GTID pour les réplicas en lecture, consultez Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID).

Bonnes pratiques pour RDS for PostgreSQL

• Si votre base de données dispose de suffisamment de mémoire libre, augmentez la valeur du paramètre logical_decoding_work_mem DB dans l'environnement bleu. Cela permet de réduire le nombre de décodages sur disque et d'utiliser de la mémoire à la place. Vous pouvez surveiller la mémoire disponible à l'aide de la FreeableMemory CloudWatch métrique. Pour plus d’informations, consultez Mesures au CloudWatch niveau de l'instance Amazon pour Amazon RDS.

• Mettez à jour toutes vos extensions PostgreSQL vers la version la plus récente avant de créer un déploiement bleu/vert. Pour plus d’informations, consultez Mise à niveau des extensions PostgreSQL.

• Si vous utilisez l'extension aws_s3, veillez à autoriser l'instance de base de données verte à accéder à Amazon S3 via un rôle IAM une fois l'environnement vert créé. Cela permet aux commandes d'importation et d'exportation de continuer à fonctionner après la commutation. Pour obtenir des instructions, veuillez consulter Configuration de l'accès à un compartiment Amazon S3.

• Si vous spécifiez une version du moteur supérieure pour l'environnement écologique, exécutez l'ANALYZEopération sur toutes les bases de données pour actualiser le pg_statistic tableau. Les statistiques de l'optimiseur ne sont pas transférées lors d'une mise à niveau de version majeure. Vous devez donc régénérer toutes les statistiques pour éviter les problèmes de performances. Pour connaître les meilleures pratiques supplémentaires lors des mises à niveau majeures des versions, consultez Comment effectuer une mise à niveau de version majeure.

• Évitez de configurer les déclencheurs au fur ENABLE REPLICA ENABLE ALWAYS et à mesure que le déclencheur est utilisé sur la source pour manipuler des données. Dans le cas contraire, le système de réplication propage les modifications et exécute le déclencheur, ce qui entraîne une duplication.

• Les transactions de longue durée peuvent entraîner un retard de réplication important. Pour réduire le délai de réplication, envisagez de procéder comme suit :

  • Réduisez les transactions de longue durée qui peuvent être retardées jusqu'à ce que l'environnement vert rattrape l'environnement bleu.

  • Lancez une opération manuelle de congélation sous vide sur les tables occupées avant de créer le déploiement bleu/vert.

  • Pour les versions 12 et supérieures de PostgreSQL, désactivez index_cleanup le paramètre sur les tables volumineuses ou occupées afin d'augmenter le taux de maintenance normale sur les bases de données bleues. Pour plus d’informations, consultez Mise à vide d'une table le plus rapidement possible.

• Une réplication lente peut entraîner des redémarrages fréquents des expéditeurs et des destinataires, ce qui retarde la synchronisation. Pour vous assurer qu'ils restent actifs, désactivez les délais d'expiration 0 en réglant le wal_sender_timeout paramètre sur l'environnement bleu et le wal_receiver_timeout paramètre sur 0 l'environnement vert.

• Pour éviter que les segments du journal d'écriture anticipée (WAL) ne soient supprimés de l'environnement bleu, définissez le wal_keep_segments paramètre sur 15625 pour PostgreSQL version 13 ou inférieure. Pour les versions 14 et supérieures, définissez le wal_keep_size paramètre sur 1 TiB, s'il y a suffisamment d'espace de stockage disponible.

Limites des déploiements bleu/vert

Les limitations suivantes s'appliquent aux déploiements bleu/vert.

Rubriques

• Limitations générales pour les déploiements bleu/vert
• Limitations des extensions PostgreSQL pour les déploiements bleu/vert
• Limitations relatives aux modifications des déploiements bleu/vert
• Limitations de la réplication logique PostgreSQL pour les déploiements bleu/vert

Limitations générales pour les déploiements bleu/vert

Les limitations générales suivantes s'appliquent aux déploiements bleu/vert :

• Les versions 8.0.11 à 8.0.13 de MySQL contiennent un bogue communautaire qui empêche leur prise en charge pour les déploiements bleu/vert.

• Les versions suivantes de RDS for PostgreSQL sont prises en charge en tant que versions source et cible de mise à niveau : 11.21 et versions ultérieures, 12.16 et versions ultérieures, 13.12 et versions ultérieures, 14.9 et versions ultérieures, et 15.4 et versions ultérieures. Pour les versions antérieures, vous pouvez mettre à niveau une version mineure vers une version prise en charge.

• Les déploiements bleu/vert ne prennent pas en charge la gestion des mots de passe des utilisateurs principaux avec. AWS Secrets Manager

• Si le volume de journal dédié (DLV) est activé sur la base de données bleue, il doit être activé sur toutes les instances de base de données, y compris les répliques de lecture.

• Pour RDS for PostgreSQL, les tables non enregistrées ne sont pas répliquées dans l'environnement vert.

• Pour RDS pour PostgreSQL, le cluster d' de base de données d'environnement bleu ne peut pas être une source logique autogérée (éditeur) ou une réplique (abonné). Pour RDS for MySQL, le d'instances de base de données de l'environnement bleu ne peut pas être une réplique externe du journal binaire.

• Lors de la commutation, les environnements bleu et vert ne peuvent pas avoir d'intégrations zéro ETL avec Amazon Redshift. Vous devez d'abord supprimer l'intégration et basculer, puis recréer l'intégration.

• Le planificateur d'événements (paramètre event_scheduler) doit être désactivé dans l'environnement vert lorsque vous créez un déploiement bleu/vert. Cela évite que des événements soient générés dans l'environnement vert et provoquent des incohérences.

• Les déploiements bleu/vert ne prennent pas en charge le pilote AWS JDBC pour MySQL. Pour plus d'informations, consultez la section Limitations connues sur GitHub.

• Les déploiements bleu/vert ne sont pas pris en charge pour les fonctionnalités suivantes :

  • Proxy Amazon RDS

  • Réplicas en lecture en cascade

  • Réplicas en lecture entre Régions

  • AWS CloudFormation

  • Déploiements de clusters de bases de données Multi-AZ

    Les déploiements bleu/vert sont pris en charge pour les déploiements d'instances de base de données multi-AZ. Pour plus d'informations sur les déploiements multi-AZ, consultez Configuration et gestion d'un déploiement multi-AZ.

Limitations des extensions PostgreSQL pour les déploiements bleu/vert

Les limitations suivantes s'appliquent aux extensions PostgreSQL :

• L'extension pg_partman doit être désactivée dans l'environnement bleu lorsque vous créez un déploiement bleu/vert. L'extension exécute des opérations DDL comme CREATE TABLE, qui interrompent la réplication logique de l'environnement bleu vers l'environnement vert.

• L'extension pg_cron doit rester désactivée dans toutes les bases de données vertes après la création du déploiement bleu/vert. L'extension dispose d'exécutants en arrière-plan qui s'exécutent en tant que superutilisateur et contournent le paramètre de lecture seule de l'environnement vert, ce qui peut provoquer des conflits de réplication.

• Si l'instance de base de données bleue est configurée en tant que serveur externe d'une extension de l'encapsuleur de données externes (FDW), vous devez utiliser le nom du point de terminaison de l'instance au lieu des adresses IP. Ainsi, la configuration reste fonctionnelle après la commutation.

• Les extensions pglogical et pg_active doivent être désactivées dans l'environnement bleu lorsque vous créez un déploiement bleu/vert. Après avoir fait de l'environnement écologique le nouvel environnement de production, vous pouvez réactiver les extensions. En outre, la base de données bleue ne peut pas être un abonné logique d'une instance externe.

• Si vous utilisez l'pgAuditextension, elle doit rester dans les bibliothèques partagées (shared_preload_libraries) sur les groupes de paramètres de base de données personnalisés pour les instances de base de données bleues et vertes. Pour plus d’informations, consultez Configuration de l'extension pgAudit.

Limitations relatives aux modifications des déploiements bleu/vert

Les limitations suivantes s'appliquent aux modifications d'un déploiement bleu/vert :

• Vous ne pouvez pas transformer une instance de base de données non chiffrée en une instance de base de données chiffrée.

• Vous ne pouvez pas transformer une instance de base de données chiffrée en une instance de base de données non chiffrée.

• Vous ne pouvez pas transmettre une instance de base de données dans l'environnement bleu vers une version de moteur supérieure à celle de son instance de base de données correspondante dans l'environnement vert.

• Les ressources de l'environnement bleu et de l'environnement vert doivent se trouver dans le même Compte AWS.

• Pour RDS for MySQL, si la base de données source est associée à un groupe d'options personnalisé, vous ne pouvez pas spécifier une mise à niveau de version majeure lorsque vous créez le déploiement bleu/vert.

  Dans ce cas, vous pouvez créer un déploiement bleu/vert sans spécifier de mise à niveau de version majeure. Ensuite, vous pouvez mettre à niveau la base de données dans l'environnement vert. Pour plus d’informations, consultez Mise à niveau de la version du moteur d'une instance de base de données.

Limitations de la réplication logique PostgreSQL pour les déploiements bleu/vert

Les déploiements bleu/vert utilisent la réplication logique pour synchroniser l'environnement intermédiaire avec l'environnement de production. PostgreSQL impose certaines restrictions de réplication logique, qui se traduisent par des limitations lors de la création de déploiements bleu/vert pour les instances de bases de données RDS for PostgreSQL.

Le tableau suivant décrit les limitations de réplication logique qui s'appliquent aux déploiements bleu/vert pour RDS for PostgreSQL.

Limitation	Explication
Les instructions DDL (Langage de définition de données), comme CREATE TABLE et CREATE SCHEMA, ne sont pas répliquées de l'environnement bleu vers l'environnement vert.	Si Amazon RDS détecte une modification DDL dans l'environnement bleu, vos bases de données vertes entrent dans un état de réplication dégradée. Un événement vous informe que les modifications DDL dans l'environnement bleu ne peuvent pas être répliquées dans l'environnement vert. Vous devez supprimer le déploiement bleu/vert et toutes les bases de données vertes, puis le recréer. Dans le cas contraire, vous ne parviendrez pas à basculer vers le déploiement bleu/vert.
Les opérations NEXTVAL sur les objets de séquence ne sont pas synchronisées entre l'environnement bleu et l'environnement vert.	Pendant la commutation, Amazon RDS incrémente les valeurs de séquence dans l'environnement vert pour les faire correspondre à celles dans l'environnement bleu. Si vous avez des milliers de séquences, cela peut retarder la commutation.
La création ou la modification d'objets volumineux dans l'environnement bleu n'est pas répliquée dans l'environnement vert.	Si Amazon RDS détecte dans l'environnement bleu la création ou la modification d'objets volumineux qui sont stockés dans la table système pg_largeobject, vos bases de données vertes entrent dans un état de réplication dégradée. RDS génère un événement vous informant que les modifications d'objets volumineux dans l'environnement bleu ne peuvent pas être répliquées dans l'environnement vert. Vous devez supprimer le déploiement bleu/vert et toutes les bases de données vertes, puis le recréer. Dans le cas contraire, vous ne parviendrez pas à basculer vers le déploiement bleu/vert.
Les vues matérialisées ne sont pas automatiquement actualisées dans l'environnement vert.	L'actualisation des vues matérialisées dans l'environnement bleu n'actualise pas les vues dans l'environnement vert. Après le basculement, vous pouvez les actualiser manuellement à l'aide de la commande REFRESH MATERIALIZED VIEW ou planifier une actualisation.
Les opérations UPDATE et DELETE ne sont pas autorisées sur les tables dépourvues de clé primaire.	Avant de créer un déploiement bleu/vert, assurez-vous que toutes les tables de l'instance de base de données possèdent une clé primaire.

Pour plus d'informations, consultez Restrictions dans la documentation Réplication logique PostgreSQL.