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

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 au cluster de base de données Aurora 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 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, le cluster de base de données et toutes ses instances de base de données sont copiés dans le déploiement. L'environnement vert comprend également les fonctionnalités utilisées par le cluster de base de données, telles que les instantanés de cluster de base de données, Performance Insights, la surveillance améliorée et Aurora Serverless v2.

Note

Les déploiements bleu/vert sont pris en charge pour Aurora MySQL et Aurora PostgreSQL. Pour connaître la disponibilité d'Amazon RDS, consultez la section Utilisation des déploiements bleu/vert d'Amazon RDS pour les mises à jour de base de données dans le guide de l'utilisateur Amazon RDS.

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 du cluster de base de données Aurora.

1. Identifiez un cluster de base de données de production qui nécessite des mises à jour.

   L'image suivante montre un exemple de cluster de base de données de production.

   

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 du cluster de base de données Aurora pour créer l'environnement vert. Les noms du cluster de base de données et des instances de base de données copiés sont complétés par -green-random-characters. L'environnement intermédiaire dans l'image contient le cluster de base de données (auroradb-green-abc123). Il contient également les trois instances de base de données du cluster de base de données (auroradb-instance1-green-abc123, auroradb-instance2-green-abc123 et auroradb-instance3-green-abc123).

   

   Lorsque vous créez le déploiement bleu/vert, vous pouvez spécifier une version supérieure du moteur de base de données et un groupe de paramètres de cluster de base de données différent pour le cluster de base de données dans l'environnement vert. Vous pouvez également spécifier un groupe de paramètres de base de données différent pour les instances de base de données dans le cluster de base de données.

   RDS configure également la réplication 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.

   Important

   Pour Aurora MySQL version 3, après avoir créé le déploiement bleu/vert, le cluster de base de données dans l'environnement vert autorise les opérations d'écriture par défaut. Nous vous recommandons de rendre le cluster de base de données en lecture seule en définissant le read_only paramètre sur 1 et en redémarrant le cluster.

3. Apportez des modifications à l'environnement intermédiaire.

   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 plus d'informations sur la modification d'un cluster de base de données, consultez Modification d'un cluster de bases de données Amazon Aurora.

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 Aurora MySQL, définissez le read_only paramètre sur0, puis redémarrez l'instance de base de données. Pour Aurora PostgreSQL, définissez default_transaction_read_only le paramètre sur au niveau de la off session.

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 clusters de bases de données après la commutation.

   

   Après la commutation, le cluster de base de données Aurora dans l'environnement vert devient le nouveau cluster 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. Le cluster de base de données et les instances de base de données dans l'environnement bleu sont renommés 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 auroradb-instance-1. Après la commutation, le nom de l'instance de base de données pourrait être auroradb-instance-1-old1.

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

   • Le cluster de base de données auroradb-green-abc123 de l'environnement vert devient le cluster de base de données de production nommé auroradb.

   • L'instance de base de données de l'environnement vert nommée auroradb-instance1-green-abc123 devient l'instance de base de données de production auroradb-instance1.

   • L'instance de base de données de l'environnement vert nommée auroradb-instance2-green-abc123 devient l'instance de base de données de production auroradb-instance2.

   • L'instance de base de données de l'environnement vert nommée auroradb-instance3-green-abc123 devient l'instance de base de données de production auroradb-instance3.

   • Le cluster de base de données de l'environnement bleu nommé auroradb devient auroradb-old1.

   • L'instance de base de données de l'environnement bleu nommée auroradb-instance1 devient auroradb-instance1-old1.

   • L'instance de base de données de l'environnement bleu nommée auroradb-instance2 devient auroradb-instance2-old1.

   • L'instance de base de données de l'environnement bleu nommée auroradb-instance3 devient auroradb-instance3-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 Aurora.

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:CreateDBCluster

• rds:CreateDBInstance

• rds:CreateDBClusterEndpoint

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

• rds:ModifyDBCluster

• rds:PromoteReadReplicaDBCluster

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:DeleteDBCluster

• rds:DeleteDBInstance

• rds:DeleteDBClusterEndpoint

Aurora 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 et le DbClusterResourceId 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 de cluster de base de données :

Le nom d'une ressource (ID de cluster) change lorsque vous passez à un déploiement bleu/vert, mais chaque ressource conserve le même ID de ressource. Par exemple, l'identifiant d'un cluster de base de données aurait pu être mycluster dans l'environnement bleu. Après la commutation, le même cluster de base de données pourrait être renommé en mycluster-old1. Cependant, l'ID de ressource du cluster 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 Aurora dansAWS CloudTrail.

• Si vous utilisez des flux d'activité de base de données pour les ressources dans l'environnement bleu, ajustez votre application pour surveiller les événements de base de données pour le nouveau flux après la commutation. Pour plus d’informations, consultez Flux d'activité de base de données dans Aurora.

• 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 .

  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 Aurora.

• Si des rôles IAM sont associés à votre 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 cluster 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 souhaitez restaurer un instantané manuel de cluster de base de données pour un cluster de base de données qui faisait partie d'un déploiement bleu/vert, assurez-vous de restaurer le bon instantané de cluster de base de données en examinant l'heure à laquelle l'instantané a été pris. Pour plus d’informations, consultez Restauration à partir d'un instantané de cluster de base de données.

• Amazon Aurora crée l'environnement vert en clonant le volume de stockage Aurora sous-jacent dans l'environnement bleu. Le volume de cluster vert stocke uniquement les modifications incrémentielles apportées à l'environnement vert. Si vous supprimez le cluster de base de données dans l'environnement bleu, la taille du volume de stockage Aurora sous-jacent dans l'environnement vert atteint sa taille complète. Pour plus d’informations, consultez Clonage d'un volume pour un cluster de base de données Amazon Aurora.

• Lorsque vous ajoutez une instance de base de données au cluster de base de données dans l'environnement vert d'un déploiement bleu/vert, la nouvelle instance de base de données ne remplacera pas une instance de base de données dans l'environnement bleu lors du basculement. Cependant, la nouvelle instance de base de données est conservée dans le cluster de base de données et devient une instance de base de données dans le nouvel environnement de production.

• Lorsque vous supprimez une instance de base de données dans le cluster de base de données de 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 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 le cluster de base de données de 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.

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 le cluster de base de données Aurora 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'une table, créer ou supprimer des index sans interrompre la réplication du déploiement bleu vers 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.

• Utilisez le point de terminaison du cluster, le point de terminaison de lecture ou le point de terminaison personnalisé pour toutes les connexions dans les deux environnements. N'utilisez pas de points de terminaison d'instance ou de points de terminaison personnalisés avec des listes statiques ou d'exclusion.

• 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 Aurora PostgreSQL

• Surveillez le cache d'écriture simultanée de la réplication logique Aurora PostgreSQL et modifiez la mémoire tampon du cache si nécessaire. Pour plus d’informations, consultez Gestion du cache d'écriture simultanée de la réplication logique d'Aurora 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 CloudWatch Métriques Amazon pour Amazon Aurora.

• 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 le cluster de base de données vert à 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.

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 sur la disponibilité des versions et des régions avec les déploiements bleu/vert Amazon RDS, consultez Déploiements bleu/vert.

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 2.08 et 2.09 d'Aurora MySQL ne sont pas prises en charge comme des versions sources ou cibles de mise à niveau.

• Vous ne pouvez pas arrêter et démarrer un cluster faisant partie d'un déploiement bleu/vert.

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

• Pour Aurora MySQL, le cluster de base de données source ne peut contenir aucune base de données nommée tmp. Les bases de données portant ce nom ne seront pas copiées dans l'environnement vert.

• Pour Aurora PostgreSQL, les tables non enregistrées ne sont pas répliquées dans l'environnement vert, sauf si le paramètre rds.logically_replicate_unlogged_tables est défini sur 1 dans le cluster de base de données bleu. Nous vous recommandons de ne pas modifier la valeur de ce paramètre après avoir créé un déploiement bleu/vert afin d'éviter d'éventuelles erreurs de réplication dans les tables non enregistrées.

• Pour Aurora PostgreSQL , le cluster d'instances de de données d'environnement bleu ne peut pas être une source logique autogérée (éditeur) ou une réplique (abonné). Pour Aurora MySQL , le cluster d' 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 politiques Aurora Auto Scaling définies sur le cluster de base de données bleu ne sont pas copiées dans l'environnement vert.

• 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 entre Régions

  • Clusters DB Aurora Serverless v1

  • Clusters de bases de données qui font partie d'une base de données globale Aurora

  • Babelfish for Aurora PostgreSQL

  • AWS CloudFormation

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.

• Le paramètre apg_plan_mgmt.capture_plan_baselines de l'extension apg_plan_mgmt doit être défini sur off dans toutes les bases de données vertes pour éviter les conflits de clés primaires si un plan identique est capturé dans l'environnement bleu. Pour plus d’informations, consultez Présentation de la gestion des plans de requêtes d'Aurora PostgreSQL.

  Si vous souhaitez capturer des plans d'exécution dans des réplicas Aurora, vous devez fournir le point de terminaison du cluster de base de données bleu lorsque vous appelez la fonction apg_plan_mgmt.create_replica_plan_capture. Les captures des plans peuvent ainsi continuer de fonctionner après la commutation. Pour plus d’informations, consultez Capture de plans d'exécution Aurora PostgreSQL dans des réplicas.

• Si le cluster de base de données bleu est configuré 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 du cluster 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 un cluster de base de données non chiffré en un cluster de base de données chiffré.

• Vous ne pouvez pas transformer un cluster de base de données chiffré en un cluster de base de données non chiffré.

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

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

• Si l'environnement bleu contient des politiques Aurora Auto Scaling, celles-ci ne sont pas copiées dans l'environnement vert. Vous devez ajouter de nouveau les politiques manuellement à l'environnement vert.

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 clusters de bases de données Aurora PostgreSQL.

Le tableau suivant décrit les limitations de réplication logique qui s'appliquent aux déploiements bleu/vert pour Aurora 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 Aurora 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, Aurora 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 Aurora 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. Aurora 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 la commutation, vous pouvez planifier une actualisation des vues matérialisées.
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 du cluster de base de données possèdent une clé primaire.

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