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. # Présentation des (Amazon Aurora Blue/Green ) En utilisant Amazon Aurora Blue/Green Deployments, 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 et reste synchronisé avec l’environnement de production actuel. Vous pouvez apporter des modifications au cluster de bases 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 faire de l’environnement vert le nouvel environnement de production. La bascule 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 bases 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 bases de données, telles que les instantanés de cluster de bases 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, Aurora PostgreSQL et Aurora Global Database. Pour connaître la disponibilité d'Amazon RDS, consultez la [présentation des Blue/Green déploiements Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/blue-green-deployments-overview.html) dans le guide de l'utilisateur *Amazon RDS*. **Topics** + [Disponibilité des régions et des versions](#blue-green-deployments-region-version-availability) + [Avantages de l'utilisation des déploiements Amazon RDS Blue/Green](#blue-green-deployments-benefits) + [Flux de travail d'un blue/green déploiement](#blue-green-deployments-major-steps) + [Autoriser l'accès aux opérations de déploiement (Amazon Aurora blue/green )](blue-green-deployments-authorizing-access.md) + [Limites et considérations relatives aux (Amazon Aurora blue/green )](blue-green-deployments-considerations.md) + [Bonnes pratiques pour les (Amazon Aurora blue/green )](blue-green-deployments-best-practices.md) ## 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 de plus amples informations, veuillez consulter [Régions prises en charge et moteurs de base de données Aurora pour les Blue/Green déploiements](Concepts.Aurora_Fea_Regions_DB-eng.Feature.BlueGreenDeployments.md). ## Avantages de l'utilisation des déploiements Amazon RDS Blue/Green En utilisant les Blue/Green déploiements Amazon RDS, vous pouvez rester au courant des correctifs de sécurité, améliorer les performances des bases de données et adopter de nouvelles fonctionnalités de base de données avec des temps d'arrêt courts et prévisibles. Blue/green les déploiements réduisent les risques et les temps d'arrêt liés aux mises à jour de base de données, telles que 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 bascule intégrées. + Éliminez les pertes de données pendant la bascule. + Basculez rapidement, généralement en moins d’une minute en fonction de votre charge de travail. ## Flux de travail d'un blue/green déploiement Effectuez les étapes principales suivantes lorsque vous utilisez un blue/green déploiement pour les mises à jour du cluster de base de données Aurora. 1. Identifiez un cluster de bases de données de production qui nécessite des mises à jour. L’image suivante montre un exemple de cluster de bases de données de production. ![\[Cluster de base de données Aurora en production (bleu) dans un blue/green déploiement\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-blue-environment-aurora.png) 1. Créez le blue/green déploiement. Pour obtenir des instructions, veuillez consulter [Création d'un blue/green déploiement dans )](blue-green-deployments-creating.md). L'image suivante montre un exemple de blue/green déploiement de l'environnement de production à partir de l'étape 1. Lors de la création du blue/green déploiement, RDS copie la topologie et la configuration complètes du cluster de base de données Aurora pour créer un environnement écologique. Les noms du cluster de bases de données et des instances de base de données copiés sont complétés par `-green-random-characters`. L'environnement de mise en scène de 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-, auroradb-instance2-green- et auroradb-instance3-green-)**abc123**. **abc123** **abc123** ![\[Déploiement bleu/vert pour Amazon Aurora\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-aurora.png) Lorsque vous créez le blue/green déploiement, 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 bases 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, une fois le blue/green déploiement créé, le cluster de base de données dans l'environnement vert n'autorise pas les opérations d'écriture par défaut. Toutefois, cela ne s’applique pas aux utilisateurs disposant du privilège `CONNECTION_ADMIN`, y compris l’utilisateur principal Aurora. Les utilisateurs dotés de ce privilège peuvent remplacer le comportement `read_only`. Pour plus d’informations, consultez [Modèle de privilège basé sur les rôles](AuroraMySQL.Compare-80-v3.md#AuroraMySQL.privilege-model). 1. Apportez des modifications à l’environnement intermédiaire. Par exemple, vous pouvez modifier la classe d’instance 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 bases de données, consultez [Modification d’un cluster de bases de données Amazon Aurora](Aurora.Modifying.md). 1. 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 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 bascule. Pour activer les opérations d’écriture pour Aurora MySQL, définissez le paramètre `read_only` sur `0`, puis redémarrez l’instance de base de données. Pour Aurora PostgreSQL, définissez le paramètre `default_transaction_read_only` sur `off` au niveau de la session. 1. Une fois prêt, basculez pour faire de l’environnement intermédiaire le nouvel environnement de production. Pour obtenir des instructions, consultez [Changer de blue/green déploiement dans )](blue-green-deployments-switching.md). La bascule entraîne une durée d’indisponibilité. La durée d’indisponibilité est généralement inférieure à une minute, mais elle peut être plus longue en fonction de votre charge de travail. L’image suivante présente les clusters de bases de données après la bascule. ![\[Cluster de base de données et instances de base de données après le transfert d'un blue/green déploiement Amazon Aurora\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/blue-green-deployment-switchover-aurora.png) Après la bascule, le cluster de bases de données Aurora dans l’environnement vert devient le nouveau cluster de bases 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 qui vient d’être basculé. Aucune modification de votre application n’est requise. En conséquence, votre trafic de production s’écoule désormais vers le nouvel environnement de production. Le cluster de bases 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 bascule, 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 bascule : + Le cluster de bases de données `auroradb-green-abc123` de l’environnement vert devient le cluster de bases 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 bases 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`. 1. Si vous n'avez plus besoin d'un blue/green déploiement, vous pouvez le supprimer. Pour obtenir des instructions, veuillez consulter [Supprimer un blue/green déploiement dans )](blue-green-deployments-deleting.md). Après la bascule, 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. # Autoriser l'accès aux opérations de déploiement (Amazon Aurora blue/green ) 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 de plus amples informations, veuillez consulter [Identity and Access Management pour Amazon Aurora](UsingWithRDS.IAM.md). L'utilisateur qui crée un blue/green déploiement doit être autorisé à effectuer les opérations RDS suivantes : + `rds:CreateBlueGreenDeployment` + `rds:AddTagsToResource` + `rds:CreateDBCluster` + `rds:CreateDBInstance` + `rds:CreateDBClusterEndpoint` L'utilisateur qui passe d'un blue/green déploiement à un autre doit être autorisé à effectuer les opérations RDS suivantes : + `rds:SwitchoverBlueGreenDeployment` + `rds:ModifyDBCluster` + `rds:PromoteReadReplicaDBCluster` L'utilisateur qui supprime un blue/green déploiement doit être autorisé à effectuer les opérations RDS suivantes : + `rds:DeleteBlueGreenDeployment` + `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 qui y sont associées ne peuvent pas contenir de modèles de noms de ressources partiels tels que `my-db-prefix-*`. Seuls les caractères génériques (\$1) 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](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonrds.html). ## Autorisations supplémentaires pour les Blue/Green déploiements de bases de données mondiales Aurora Lors de la création de blue/green déploiements pour les clusters de base de données globale Aurora, outre les autorisations répertoriées ci-dessus, les utilisateurs ont besoin des autorisations suivantes pour effectuer des opérations de gestion de la topologie du cluster global. L'utilisateur qui crée un blue/green déploiement doit être autorisé à effectuer les opérations RDS suivantes : + `rds:CreateGlobalCluster` L'utilisateur qui passe d'un blue/green déploiement à un autre doit être autorisé à effectuer les opérations RDS suivantes : + `rds:ModifyGlobalCluster` + `rds:PromoteReadReplicaDBCluster` L'utilisateur qui supprime un blue/green déploiement doit être autorisé à effectuer les opérations RDS suivantes : + `rds:DeleteGlobalCluster` # Limites et considérations relatives aux (Amazon Aurora blue/green ) Les déploiements bleu/vert dans Amazon RDS nécessitent une prise en compte attentive de facteurs tels que les emplacements de réplication, la gestion des ressources, le dimensionnement des instances et les impacts potentiels sur les performances de la base de données. Les sections suivantes fournissent des conseils pour vous aider à optimiser votre stratégie de déploiement afin de garantir une durée d’indisponibilité minimale, des transitions fluides et une gestion efficace de votre environnement de base de données. **Topics** + [Limitations relatives aux blue/green déploiements](#blue-green-deployments-limitations) + [Limites de la base de données globale Aurora pour les blue/green déploiements](#blue-green-deployments-limitations-agd) + [Considérations relatives aux blue/green déploiements](#blue-green-deployments-consider) ## Limitations relatives aux blue/green déploiements Les limitations suivantes s'appliquent aux blue/green déploiements. **Topics** + [Limitations générales relatives aux blue/green déploiements](#blue-green-deployments-limitations-general) + [Limitations d'Aurora MySQL les déploiements blue/green](#blue-green-deployments-limitations-mysql) + [](#blue-green-deployments-limitations-postgres-logical) ### Limitations générales relatives aux blue/green déploiements Les limitations générales suivantes s'appliquent aux blue/green déploiements : + Vous ne pouvez pas arrêter et démarrer un cluster faisant partie d'un blue/green déploiement. + Les déploiements bleu/vert ne prennent pas en charge la gestion des mots de passe des utilisateurs principaux avec AWS Secrets Manager. + Si vous tentez de forcer le cluster de base de données bleu à revenir en arrière, le blue/green déploiement est interrompu et le basculement est bloqué. + Lors de la bascule, 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 (`event_scheduler`paramètre) doit être désactivé dans l'environnement vert lorsque vous créez un blue/green déploiement. Cela évite que des événements soient générés dans l’environnement vert et provoquent des incohérences. + Les politiques d’autoscaling configurées sur le cluster de bases de données bleu ne sont pas copiées dans l’environnement vert. Vous devez les reconfigurer après la bascule, qu’elles aient été initialement configurées dans l’environnement bleu ou vert. + Vous ne pouvez pas transformer un cluster de bases de données non chiffré en un cluster de bases de données chiffré. En outre, vous ne pouvez pas transformer un cluster de bases de données chiffré en cluster de bases de données non chiffré. + Vous ne pouvez pas transmettre un cluster de bases de données bleu vers une version de moteur supérieure à celle de son cluster de bases de données vert correspondant. + Les ressources de l’environnement bleu et de l’environnement vert doivent se trouver dans le même Compte AWS. + 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 + CloudFormation ### Limitations d'Aurora MySQL les déploiements blue/green Les limitations suivantes s'appliquent aux blue/green déploiements Aurora MySQL  : + Le cluster de bases 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. + Le cluster de bases de données bleu ne peut pas être un réplica externe du journal binaire. + Si le retour sur trace est activé pour le cluster de bases de données source, le cluster de bases de données vert est créé sans prise en charge du retour sur trace. Cela est dû au fait que le retour en arrière ne fonctionne pas avec la réplication des journaux binaires (binlog), qui est requise pour les blue/green déploiements. Pour de plus amples informations, veuillez consulter [Retour en arrière d’un cluster de bases de données Aurora](AuroraMySQL.Managing.Backtrack.md). + 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](https://github.com/awslabs/aws-mysql-jdbc?tab=readme-ov-file#known-limitations) sur GitHub. ### Les limitations suivantes s’appliquent aux déploiements bleu/vert Aurora PostgreSQL . + Les tables [non journalisées](https://www.postgresql.org/docs/16/sql-createtable.html#SQL-CREATETABLE-UNLOGGED) 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 bases de données bleues. Ne modifiez pas cette valeur de paramètre après avoir créé un blue/green déploiement afin d'éviter d'éventuelles erreurs de réplication sur les tables non enregistrées. + Le cluster de bases de données bleues ne peut pas être une source logique (diffuseur de publication) ou un réplica (abonné). + Si le cluster de bases 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 bascule. + Lors d'un blue/green déploiement, chaque base de données nécessite un emplacement de réplication logique. À mesure que le nombre de bases de données augmente, la surcharge en ressources augmente et peut potentiellement entraîner un retard de réplication, en particulier si la mise à l’échelle du cluster de bases de données est insuffisante. L’impact dépend de facteurs tels que la charge de travail de la base de données et le nombre de connexions. Pour atténuer ce problème, pensez à augmenter verticalement votre classe d’instance de base de données ou à réduire le nombre de bases de données sur l’instance source. + Les déploiements bleu/vert sont pris en charge pour Babelfish pour Aurora PostgreSQL uniquement pour la version 15.7 et versions 15 ultérieures, et la version 16.3 et versions 16 ultérieures. + Si vous souhaitez capturer des plans d’exécution dans des réplicas Aurora, vous devez fournir le point de terminaison du cluster de bases 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 bascule. Pour plus d’informations, consultez [Capture de plans d’exécution Aurora PostgreSQL dans des réplicas](AuroraPostgreSQL.QPM.Plancapturereplicas.md). + Le [processus d’application](https://www.postgresql.org/docs/current/logical-replication-architecture.html) de la réplication logique dans un environnement vert est à thread unique. Si l’environnement bleu génère un volume élevé de trafic d’écriture, l’environnement vert risque de ne pas être en mesure de suivre le rythme. Cela peut entraîner un retard ou un échec de réplication, en particulier pour les charges de travail qui produisent un débit d’écriture élevé en continu. Assurez-vous de tester minutieusement vos charges de travail. Pour les scénarios nécessitant des mises à niveau des versions majeures et la gestion de charges de travail d’écriture de gros volumes, envisagez d’autres approches telles que l’utilisation de [AWS Database Migration Service (AWS DMS)](https://docs.aws.amazon.com/dms/latest/userguide/data-migrations.html) ou la [réplication logique autogérée](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/AuroraPostgreSQL.MajorVersionUpgrade.html). + La création de partitions sur des tables partitionnées n’est pas prise en charge lors des déploiements bleu/vert pour Aurora. La création de partitions implique des opérations de langage de définition des données (DDL) comme `CREATE TABLE`, qui ne sont pas répliquées entre l’environnement bleu et l’environnement vert. Cependant, les tables partitionnées existantes et leurs données sont répliquées dans l’environnement vert. + Les limitations suivantes s’appliquent aux extensions PostgreSQL : + L'`pg_partman`extension doit être désactivée dans l'environnement bleu lorsque vous créez un blue/green déploiement. 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'`pg_cron`extension doit rester désactivée sur toutes les bases de données vertes après la création du blue/green déploiement. 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 de plus amples informations, veuillez consulter [Présentation de la gestion des plans de requêtes d’Aurora PostgreSQL](AuroraPostgreSQL.Optimize.overview.md). + Les `pgactive` extensions `pglogical` et doivent être désactivées dans l'environnement bleu lorsque vous créez un blue/green déploiement. Après avoir basculé l’environnement vert comme 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’extension `pgAudit`, 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 de plus amples informations, veuillez consulter [Configuration de l’extension pgAudit](Appendix.PostgreSQL.CommonDBATasks.pgaudit.basic-setup.md). #### Limitations spécifiques à la réplication logique pour les déploiements blue/green Le tableau suivant décrit les limitations de réplication logique qui s’appliquent aux déploiements bleu/vert pour Aurora PostgreSQL. Pour plus d’informations, consultez [Restrictions](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) dans la documentation Réplication logique 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**. Vous devez supprimer le blue/green déploiement et toutes les bases de données vertes, puis les recréer. | | Les instructions de langage de contrôle de données (DCL), comme GRANT et REVOKE, ne sont pas répliquées de l’environnement bleu vers l’environnement vert. | Si Aurora détecte une tentative d’exécution d’une instruction DCL dans l’environnement bleu, un message d’avertissement s’affiche. Aucune configuration ou API n'est disponible pour modifier ce comportement, car il s'agit d'une limitation du processus de blue/green déploiement. | | 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 bascule, 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 bascule. | | Les objets volumineux dans l’environnement bleu ne sont pas répliqués dans l’environnement vert. Cela inclut à la fois les grands objets existants et tous les grands objets nouvellement créés ou modifiés au cours du processus de blue/green déploiement. | 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**. Vous devez supprimer le blue/green déploiement et toutes les bases de données vertes, puis les recréer. | | L’actualisation des vues matérialisées interrompt la réplication. | L’actualisation des vues matérialisées dans l’environnement bleu interrompt la réplication dans l’environnement vert. Évitez d’actualiser les vues matérialisées dans l’environnement bleu. Après la bascule, vous pouvez les actualiser manuellement à l’aide de la commande [REFRESH MATERIALIZED VIEW](https://www.postgresql.org/docs/current/sql-refreshmaterializedview.html) 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 blue/green déploiement, assurez-vous que toutes les tables disposent d'une clé primaire ou d'une utilisation`REPLICA IDENTITY FULL`. Toutefois, utilisez `REPLICA IDENTITY FULL` uniquement s’il n’existe aucune clé primaire ou unique, car cela affecte les performances de réplication. Pour plus d’informations, consultez la [documentation sur PostgreSQL](https://www.postgresql.org/docs/current/logical-replication-restrictions.html). | ## Limites de la base de données globale Aurora pour les blue/green déploiements Outre les limitations générales et spécifiques au moteur indiquées ci-dessus, les limitations suivantes s'appliquent aux blue/green déploiements pour Aurora Global Database : + Toutes les opérations doivent être lancées depuis la même région que le cluster de rédacteurs de la base de données globale. + L'exécution d'un basculement global ou d'un basculement global entraînera l'invalidité du blue/green déploiement actif. Le déploiement bleu-vert doit être supprimé et recréé à partir de la nouvelle région principale. + Pour Aurora PostgreSQL, si le transfert d'écriture global est activé dans votre environnement de production et que vous créez blue/green un déploiement, le transfert d'écriture est désactivé sur le cluster vert. Il n'est activé dans l'environnement vert qu'après le blue/green passage au numérique, lorsque l'environnement vert devient le nouvel environnement de production. Après le basculement, le transfert d'écriture est désactivé sur le `-old1` cluster. + La modification de la topologie de la base de données globale après la création du blue/green déploiement entraînera l'invalidité du blue/green déploiement actif. Le déploiement bleu-vert devrait être supprimé et recréé à partir de la nouvelle région principale. + Les instantanés automatisés sont conservés selon le nombre de jours de conservation des sauvegardes initialement configurés dans l'ancien environnement bleu. Les instantanés automatisés de l'ancien cluster bleu ne sont pas copiés en vert. + Le basculement global est pris en charge lors d'un blue/green basculement, mais un basculement global n'est pas pris en charge lors d'un basculement. blue/green + Assurez-vous que le cluster de base de données et les groupes de paramètres de base de données pour l'environnement écologique existent dans toutes les régions secondaires avec des noms identiques. Si le groupe de paramètres d'une région n'est pas disponible, le groupe de paramètres par défaut des régions est utilisé. + Évitez d'utiliser le proxy RDS sur les membres de la base de données globale lors du changement blue/green de déploiement. ## Considérations relatives aux blue/green déploiements Amazon RDS suit les ressources lors des blue/green déploiements à l'aide de la `DbiResourceId` fin `DbClusterResourceId` de chaque ressource. Cet identifiant de ressource est un identifiant Région AWS unique et immuable pour la ressource. L’identifiant de *ressource* est distinct de l’identifiant *de cluster de bases de données*** : Chacun d’entre eux est répertorié dans la configuration de base de données de la console RDS. Le nom (ID de cluster) d'une ressource change lorsque vous changez de blue/green déploiement, mais chaque ressource conserve le même ID de ressource. Par exemple, l’identifiant d’un cluster de bases de données aurait pu être `mycluster` dans l’environnement bleu. Après la bascule, le même cluster de bases de données pourrait être renommé en `mycluster-old1`. Cependant, l’ID de ressource du cluster de bases de données ne change pas pendant la bascule. Ainsi, lorsque vous remplacez les ressources vertes par les nouvelles ressources de production, leur ressource IDs ne correspond pas à la ressource bleue IDs qui était auparavant en production. Après avoir transféré un blue/green déploiement, envisagez de mettre à jour la ressource IDs pour qu'elle corresponde à celles des ressources de production récemment transférées pour les fonctionnalités et les 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 et de la ressource RDS IDs, ajustez la ressource IDs utilisée pour le filtrage après le passage au numérique. + Si vous l'utilisez CloudTrail pour auditer des ressources, ajustez les consommateurs de CloudTrail afin de suivre la nouvelle ressource IDs après le passage au numérique. Pour de plus amples informations, veuillez consulter [Surveillance des appels d'API Amazon Aurora dansAWS CloudTrail](logging-using-cloudtrail.md). + 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 bascule. Pour de plus amples informations, veuillez consulter [Régions et moteurs de base de données Aurora pris en charge pour les flux d’activité de base de données](Concepts.Aurora_Fea_Regions_DB-eng.Feature.DBActivityStreams.md). + Si vous utilisez l'API Performance Insights, ajustez la ressource IDs dans les appels à l'API après le passage au numérique. Pour de plus amples informations, veuillez consulter [Surveillance de la charge de la base de données avec Performance Insights sur ](USER_PerfInsights.md). Vous pouvez surveiller une base de données avec le même nom après la bascule, mais elle ne contient pas les données d’avant la bascule. + Si vous utilisez des ressources IDs dans les politiques IAM, assurez-vous d'ajouter la ressource IDs des ressources récemment transférées lorsque cela est nécessaire. Pour de plus amples informations, veuillez consulter [Identity and Access Management pour Amazon Aurora](UsingWithRDS.IAM.md). + Si des rôles IAM sont associés à votre cluster de bases de données, veillez à les réassocier après la bascule. 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 bases de données à l’aide de l’[authentification de base de données IAM](UsingWithRDS.IAMDBAuth.md), 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 bascule. Pour de plus amples informations, veuillez consulter [Création et utilisation d'une politique IAM pour l'accès à une base de données IAM](UsingWithRDS.IAMDBAuth.IAMPolicy.md). + Si vous souhaitez restaurer un instantané de cluster de base de données manuel pour un cluster de base de données faisant partie d'un blue/green déploiement, assurez-vous de restaurer le cliché de cluster de base de données correct en examinant l'heure à laquelle le cliché a été pris. Pour de plus amples informations, veuillez consulter [Restauration à partir d’un instantané de cluster de bases de données](aurora-restore-snapshot.md). + Après le changement, AWS Database Migration Service (AWS DMS) les tâches de réplication ne peuvent pas reprendre car le point de contrôle de l'environnement bleu n'est pas valide dans l'environnement vert. Vous devez recréer la tâche DMS avec un nouveau point de contrôle pour poursuivre la réplication. + 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 bases 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 bases de données Amazon Aurora](Aurora.Managing.Clone.md). + Lorsque vous ajoutez une instance de base de données au cluster de bases 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 bases 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 dans l'environnement vert d'un blue/green deployment, you can't create a new DB instance to replace it in the blue/green déploiement. 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 bases 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 bascule. + Si vous utilisez des balises de ressources pour le contrôle d'accès ou la gestion opérationnelle, vous devez comprendre que les modifications des balises ne sont pas synchronisées entre les environnements bleu et vert avant le passage au numérique. Lorsque vous créez un blue/green déploiement, les balises de l'environnement bleu sont copiées dans l'environnement vert. Après la création, les modifications de balises que vous apportez à l'un ou l'autre environnement ne sont pas automatiquement synchronisées. Lors du passage au numérique, les balises d'environnement bleues remplacent toutes les balises de l'environnement vert. Appliquez toutes les balises nécessaires à l'environnement bleu avant de créer le blue/green déploiement, ou réappliquez les balises requises au nouvel environnement de production après le passage au numérique. Pour en savoir plus sur les identifications, consultez [Marquage des ressources Amazon Aurora et Amazon RDS](USER_Tagging.md). # Bonnes pratiques pour les (Amazon Aurora blue/green ) Les meilleures pratiques pour les blue/green déploiements sont les suivantes. **Topics** + [Bonnes pratiques générales pour les blue/green déploiements](#blue-green-deployments-best-practices-general) + [ : bonnes pratiques pour les déploiements blue/green](#blue-green-deployments-best-practices-mysql) + [Meilleures pratiques d'Aurora PostgreSQL pour les déploiements blue/green](#blue-green-deployments-best-practices-postgres) + [Bonnes pratiques relatives à la base de données globale Aurora pour les déploiements blue/green](#blue-green-deployments-best-practices-agd) ## Bonnes pratiques générales pour les blue/green déploiements Tenez compte des bonnes pratiques générales suivantes lorsque vous créez un déploiement bleu/vert. + Testez minutieusement le cluster de bases 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. + Si vous utilisez un blue/green déploiement pour implémenter des modifications de schéma, apportez uniquement des modifications compatibles avec la réplication. Par exemple, vous pouvez ajouter de nouvelles colonnes à la fin d’une table 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](https://dev.mysql.com/doc/refman/8.0/en/replication-features-differing-tables.html) dans la documentation MySQL, et [Restrictions](https://www.postgresql.org/docs/current/logical-replication-restrictions.html) 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 passez d'un blue/green déploiement à un autre, suivez les meilleures pratiques en la matière. Pour de plus amples informations, veuillez consulter [Bonnes pratiques de bascule](blue-green-deployments-switching.md#blue-green-deployments-switching-best-practices). ##  : bonnes pratiques pour les déploiements blue/green Tenez compte des meilleures pratiques suivantes lorsque vous créez un blue/green déploiement à partir d'un cluster de base de données Aurora MySQL. + Si l’environnement vert connaît un retard de réplica, tenez compte des éléments suivants : + Désactivez la conservation des journaux binaires si elle n’est pas nécessaire, ou désactivez-la temporairement jusqu’à ce que la réplication rattrape son retard. Pour ce faire, redéfinissez le paramètre du cluster de bases de données `binlog_format` sur `0` et redémarrez l’instance de base de données d’enregistreur verte. + Définissez temporairement le paramètre `innodb_flush_log_at_trx_commit` sur `0` dans le groupe de paramètres de base de données vert. Une fois que la réplication a rattrapé son retard, revenez à la valeur par défaut de `1` avant la bascule. Si un arrêt ou un incident inattendu survient avec la valeur du paramètre temporaire, reconstruisez l’environnement vert pour éviter toute corruption de données non détectée. Pour plus d’informations, consultez [Configuration de la fréquence à laquelle le tampon du journal est vidé](AuroraMySQL.BestPractices.FeatureRecommendations.md#AuroraMySQL.BestPractices.Flush). ## Meilleures pratiques d'Aurora PostgreSQL pour les déploiements blue/green Tenez compte des meilleures pratiques suivantes lorsque vous créez un blue/green déploiement à partir d'un cluster de base de données 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 [Surveillance du cache à écriture simultanée de la réplication logique Aurora PostgreSQL](AuroraPostgreSQL.Replication.Logical-monitoring.md#AuroraPostgreSQL.Replication.Logical-write-through-cache). + Augmentez la valeur du paramètre de base de données `logical_decoding_work_mem` 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. Pour de plus amples informations, veuillez consulter [Ajustement de la mémoire de travail pour le décodage logique](AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.md#AuroraPostgreSQL.BestPractices.Tuning-memory-parameters.logical-decoding-work-mem). + Vous pouvez surveiller le dépassement des transactions écrites sur le disque à l'aide de la `ReplicationSlotDiskUsage` CloudWatch métrique. Cette métrique fournit des informations sur l’utilisation des emplacements de réplication sur le disque, ce qui permet d’identifier les cas où les données de transaction dépassent la capacité de mémoire et sont stockées sur disque. Vous pouvez surveiller la mémoire disponible à l'aide de la `FreeableMemory` CloudWatch métrique. Pour de plus amples informations, veuillez consulter [Métriques de niveau instance pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md#Aurora.AuroraMySQL.Monitoring.Metrics.instances). + Dans Aurora PostgreSQL versions 14 et ultérieures, vous pouvez surveiller la taille des fichiers de dépassement logique à l’aide de la vue système `[pg\$1stat\$1replication\$1slots](https://www.postgresql.org/docs/14/monitoring-stats.html#MONITORING-PG-STAT-REPLICATION-SLOTS-VIEW)`. + Mettez à jour toutes vos extensions PostgreSQL vers la dernière version avant de créer un déploiement. blue/green Pour de plus amples informations, veuillez consulter [Mise à niveau des extensions PostgreSQL](USER_UpgradeDBInstance.Upgrading.ExtensionUpgrades.md). + Si vous utilisez l’extension `aws_s3`, autorisez le cluster de bases 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 bascule. Pour obtenir des instructions, consultez [Configuration de l’accès à un compartiment Amazon S3](postgresql-s3-export-access-bucket.md). + Si vous spécifiez une version du moteur supérieure pour l’environnement vert, exécutez l’opération `ANALYZE` sur toutes les bases de données pour actualiser la table `pg_statistic`. 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 bonnes pratiques supplémentaires lors des mises à niveau des versions majeures, consultez [Réalisation d’une mise à niveau de version majeure](USER_UpgradeDBInstance.PostgreSQL.MajorVersion.md). + Évitez de configurer les déclencheurs comme `ENABLE REPLICA` ou `ENABLE ALWAYS` si 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éplica important. Pour réduire le retard de réplica, envisagez les opérations suivantes : + Réduisez les transactions de longue durée et les sous-transactions qui peuvent être retardées jusqu’à ce que l’environnement vert rattrape l’environnement bleu. + Réduisez les opérations en bloc dans l’environnement bleu 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 blue/green déploiement. Pour obtenir des instructions, consultez [Réalisation d’un gel manuel du processus vacuum](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.VacuumFreeze.html). + Dans PostgreSQL versions 12 et ultérieures, désactivez le paramètre `index_cleanup` sur les tables volumineuses ou occupées afin d’améliorer l’efficacité de la maintenance régulière des bases de données bleues. Pour plus d’informations, consultez [Vidage d’une table le plus rapidement possible](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.html#Appendix.PostgreSQL.CommonDBATasks.Autovacuum.LargeIndexes.Executing). **Note** Le fait de ne pas nettoyer régulièrement l’index pendant l’opération de vacuum peut entraîner un gonflement de l’index, ce qui peut dégrader les performances d’analyse. Il est recommandé d'utiliser cette approche uniquement lors d'un blue/green déploiement. Une fois le déploiement terminé, nous vous recommandons de reprendre la maintenance et le nettoyage réguliers de l’index. + Un retard de réplica peut se produire si les instances de base de données bleues et vertes sont sous-dimensionnées par rapport à la charge de travail. Assurez-vous que vos instances de base de données n’atteignent pas leurs limites de ressources pour le type d’instance. Pour plus d’informations, consultez [Utilisation des CloudWatch métriques Amazon pour analyser l'utilisation des ressources pour Aurora PostgreSQL](AuroraPostgreSQL_AnayzeResourceUsage.md). + 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 en réglant le paramètre `wal_sender_timeout` sur `0` dans l’environnement bleu et le paramètre `wal_receiver_timeout` sur `0` dans l’environnement vert. + Vérifiez les performances de vos instructions UPDATE et DELETE et déterminez si la création d’un index sur la colonne utilisée dans la clause WHERE peut optimiser ces requêtes. Cela peut améliorer les performances lorsque les opérations sont réexécutées dans un environnement vert. Pour plus d’informations, consultez [Vérifiez les filtres de prédicat pour détecter les requêtes qui génèrent des attentes](apg-waits.iodatafileread.md#apg-waits.iodatafileread.actions.filters). + Si vous utilisez des déclencheurs, assurez-vous qu’ils n’interfèrent pas avec la création, la mise à jour et la suppression d’objets `pg_catalog.pg_publication`, `pg_catalog.pg_subscription` et `pg_catalog.pg_replication_slots` dont le nom commence par « rds ». + Si Babelfish est activé sur le cluster de bases de données source, les paramètres suivants doivent avoir les mêmes paramètres dans le groupe de paramètres du cluster de bases de données cible pour l’environnement vert que dans le groupe de paramètres du cluster de bases de données source : + rds.babelfish\$1status + babelfishpg\$1tds.tds\$1default\$1numeric\$1precision + babelfishpg\$1tds.tds\$1default\$1numeric\$1scale + babelfishpg\$1tsql.default\$1locale + babelfishpg\$1tsql.migration\$1mode + babelfishpg\$1tsql.server\$1collation\$1name Pour obtenir plus d’informations sur ces paramètres, consultez [Paramètres du groupe de paramètres de cluster de bases de données pour Babelfish](babelfish-configuration.md). ## Bonnes pratiques relatives à la base de données globale Aurora pour les déploiements blue/green Outre les meilleures pratiques générales et spécifiques au moteur répertoriées ci-dessus, tenez compte des meilleures pratiques suivantes pour l' Global Database. + Surveillez les CloudWatch indicateurs suivants pour identifier les périodes de faible activité dans votre environnement de production : + `DatabaseConnections` + `ActiveTransactions` Planifiez le blue/green passage au numérique pendant votre période de maintenance planifiée ou pendant une période de faible activité. + Blue/Green switchover duration varies based on your workload and the number of secondary regions. When you initiate a blue/greenlors du basculement, le service attend que le délai de réplication atteigne zéro avant de poursuivre. Nous vous recommandons de vérifier le délai de réplication avant de lancer un changement. + Si vous avez l'intention d'utiliser un paramètre de base de données ou un groupe de paramètres de cluster de base de données autre que celui par défaut pour votre environnement écologique, créez le groupe de paramètres souhaité portant le même nom dans toutes les régions secondaires avant de lancer le blue/green déploiement.