Limites et considérations relatives aux (Amazon Aurora blue/green ) - Amazon Aurora
LimitationsConsidérations

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.

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.

Limitations relatives aux blue/green déploiements

Les limitations suivantes s'appliquent aux blue/green déploiements.

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

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_schedulerparamè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

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

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

  • 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 limitations suivantes s’appliquent aux déploiements bleu/vert Aurora PostgreSQL .

  • Les tables non journalisé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 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.

  • Le processus d’application 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) ou la réplication logique autogérée.

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

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

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

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

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

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

    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.

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

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

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

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

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