Limitations et considérations relatives aux déploiements bleu/vert d' (Amazon Aurora) - Amazon Aurora
LimitesConsidé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.

Limitations et considérations relatives aux déploiements bleu/vert d' (Amazon Aurora)

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 des temps d'arrêt minimaux, des transitions fluides et une gestion efficace de votre environnement de base de données.

Limites des déploiements bleu/vert

Les limitations suivantes s'appliquent aux 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 :

  • 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

  • Si vous tentez de forcer un retour en arrière sur le cluster de base de données bleu, le déploiement bleu/vert est interrompu et le basculement est bloqué.

  • 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 Auto Scaling configurées sur le cluster de base de données bleu ne sont pas copiées dans l'environnement vert. Vous devez les reconfigurer après le passage au numérique, qu'ils aient été initialement configurés dans l'environnement bleu ou 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 remplacer un cluster d' de base de données bleu par une version de moteur supérieure à celle du cluster d' de base 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

    • AWS CloudFormation

Limitations d'Aurora MySQL déploiements bleu/vert

Les limitations suivantes s'appliquent aux déploiements bleu/vert Aurora MySQL  :

  • Le cluster de base de données source ne peut contenir aucune base de données nomméetmp. Les bases de données portant ce nom ne seront pas copiées dans l'environnement vert.

  • Le cluster d' DB bleu ne peut pas être une réplique externe du journal binaire.

  • Si le cluster de base de données source pour lequel le retour en arrière est activé, le cluster de base de données vert est créé sans support de retour en arrière. Cela est dû au fait que le retour en arrière ne fonctionne pas avec la réplication du journal binaire (binlog), qui est requise pour les déploiements bleu/vert. Pour de plus amples informations, veuillez consulter Retour sur trace d'un cluster de base 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 tables non enregistrées ne sont pas répliquées dans l'environnement vert sauf si le rds.logically_replicate_unlogged_tables paramètre est défini 1 sur le cluster de base de données bleu. Ne modifiez pas la valeur de ce paramètre après avoir créé un déploiement bleu/vert afin d'éviter d'éventuelles erreurs de réplication sur les tables non enregistrées.

  • Le cluster d' DB bleu ne peut pas être une source logique (éditeur) ou une réplique (abonné).

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

  • Dans un déploiement bleu/vert, 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 l' de bases de données n'est pas suffisamment dimensionnée. 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 à étendre votre classe d'instance de base de données ou à réduire le nombre de bases de données sur l' de cluster source.

  • Les déploiements bleu/vert sont pris en charge pour Babelfish pour Aurora PostgreSQL uniquement pour les versions 15.7 et supérieures 15, et les versions 16.3 et supérieures 16.

  • 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 de plus amples informations, veuillez consulter Capture de plans d'exécution Aurora PostgreSQL dans des réplicas.

  • Le processus d'application de la réplication logique dans un environnement écologique est monothread. 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 de version majeures et la gestion de charges de travail d'écriture de volumes élevés, envisagez d'autres approches telles que l'utilisation de AWS Database Migration Service (AWS DMS) ou la réplication logique autogérée.

  • 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 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 de plus amples informations, veuillez consulter Présentation de la gestion des plans de requêtes d'Aurora PostgreSQL.

    • Les extensions pglogical et pgactive doivent être désactivées dans l'environnement bleu lorsque vous créez un déploiement bleu/vert. Après avoir remplacé l'environnement vert par 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 de plus amples informations, veuillez consulter Configuration de l' pgAudit extension.

Limitations spécifiques à la réplication logique pour les déploiements bleu/vert

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. 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 déploiement bleu/vert et toutes les bases de données vertes, puis le recréer.
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.
Les objets de grande taille 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 déploiement bleu/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. Vous devez supprimer le déploiement bleu/vert et toutes les bases de données vertes, puis le 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 de rafraîchir les vues matérialisées dans l'environnement bleu. Après un basculement, vous pouvez les actualiser manuellement à l'aide de la commande REFRESH MATERIALIZED VIEW ou planifier une actualisation.

Les opérations UPDATE et DELETE ne sont pas autorisées sur les tables dépourvues de clé primaire.

Avant de créer un déploiement bleu/vert, assurez-vous que toutes les tables disposent d'une clé primaire ou d'une clé d'utilisation. REPLICA IDENTITY FULL Toutefois, ne l'utilisez que REPLICA IDENTITY FULL s'il n'existe aucune clé primaire ou unique, car cela affecte les performances de réplication. Pour de plus amples informations, veuillez consulter la documentation sur PostgreSQL.

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 d' de cluster de base de données. Chacun d'entre eux est répertorié dans la configuration de base de données de la console RDS.

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 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 basculé vers un déploiement bleu/vert, envisagez de mettre à jour la ressource en IDs fonction de 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 d'Amazon Aurora ( API appelle) AWS 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 de plus amples informations, veuillez consulter Régions et moteurs de base de données Aurora pris en charge pour les flux d'activité des bases 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 commutation, mais elle ne contient pas les données d'avant la commutation.

  • 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 Gestion des identités et des accès 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 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é 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 de plus amples informations, veuillez consulter Restauration à partir d'un instantané de cluster de base 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 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 de plus amples informations, veuillez consulter 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 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 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.