Limitations et considérations relatives aux déploiements bleu/vert d'Amazon RDS - Amazon Relational Database Service
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 RDS

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 :

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

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

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

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

  • Vous ne pouvez pas remplacer un d'instances de base de données bleu par une version de moteur supérieure à celle du d'instances 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 en cascade

    • Réplicas en lecture entre Régions

    • AWS CloudFormation

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

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

Limitations d'RDS pour MySQL pour les déploiements bleu/vert

Les limitations suivantes s'appliquent aux RDS pour MySQL :

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

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

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

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

Limitations de RDS pour PostgreSQL pour les déploiements bleu/vert avec réplication physique

Les limitations suivantes s'appliquent aux déploiements RDS pour blue/green deployments that use physical replication. For an explanation of when blue/green PostgreSQL utilisant la réplication physique plutôt que la réplication logique, voir. Méthodes de SQL réplication Postgre pour les déploiements bleu/vert

  • Une fois l'environnement écologique créé, vous ne pouvez pas effectuer de mise à niveau manuelle de la version majeure.

  • Les déploiements bleu/vert qui utilisent la réplication physique ne prennent pas en charge les modifications de schéma dans l'environnement vert, car celui-ci est strictement en lecture seule.

  • L'instance de base de données bleue ne peut pas être une source logique (éditeur) ou une réplique (abonné).

Limitations d' RDS pour PostgreSQL pour les déploiements bleu/vert avec réplication logique

Les limitations suivantes s'appliquent aux déploiements RDS pour PostgreSQL qui utilisent la réplication logique. Pour savoir dans quels cas les déploiements bleu/vert utilisent la réplication logique au lieu de la réplication physique, voir. Méthodes de SQL réplication Postgre pour les déploiements bleu/vert

  • Les tables non enregistrées ne sont pas répliquées dans l'environnement vert .

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

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

  • 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'instance de base de 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'instance de source.

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

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

    • 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 instances de bases de données RDS for PostgreSQL.

Le tableau suivant décrit les limitations de réplication logique qui s'appliquent aux déploiements bleu/vert pour RDS for PostgreSQL. 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 Amazon RDS détecte une modification DDL dans l'environnement bleu, vos bases de données vertes entrent dans un état de réplication dégradée. 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, Amazon RDS incrémente les valeurs de séquence dans l'environnement vert pour les faire correspondre à celles dans l'environnement bleu. Si vous avez des milliers de séquences, cela peut retarder la commutation.
La création ou la modification d'objets volumineux dans l'environnement bleu n'est pas répliquée dans l'environnement vert.

Si Amazon RDS détecte dans l'environnement bleu la création ou la modification d'objets volumineux qui sont stockés dans la table système pg_largeobject, vos bases de données vertes entrent dans un état de réplication dégradée. Vous devez supprimer le déploiement bleu/vert et toutes les bases de données vertes, puis le recréer.

Les vues matérialisées ne sont pas automatiquement actualisées dans l'environnement vert.

L'actualisation des vues matérialisées dans l'environnement bleu n'actualise pas les vues dans l'environnement vert. Après le basculement, vous pouvez les actualiser manuellement à l'aide de la commande REFRESH MATERIALIZED VIEW ou planifier une actualisation.

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

Avant de créer un déploiement bleu/vert, assurez-vous que toutes les tables 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 de chaque ressource. Cet identifiant de ressource est un identifiant Région AWS unique et immuable pour la ressource.

L'ID de ressource est distinct de l'ID d'instance de 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 d'instance) change lorsque vous passez à un déploiement bleu/vert, mais chaque ressource conserve le même ID de ressource. Par exemple, l'identifiant d'une instance de base de données peut être mydb dans l'environnement bleu. Après la commutation, la même instance de base de données peut être renommée en mydb-old1. Cependant, l'ID de ressource de l'instance de base de données ne change pas pendant la commutation. Ainsi, lorsque 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 (Amazon RDS API appelle) AWS CloudTrail.

  • 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 base de données avec Performance Insights sur RDSAmazon.

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

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

  • Si vous vous authentifiez auprès de votre instance de base de données à l'aide de l'authentification de base de données IAM, veillez à ce que la politique IAM utilisée pour accéder à la base de données contienne à la fois les bases de données bleues et vertes répertoriées sous l'élément Resource de la politique. Cela est nécessaire pour se connecter à la base de données verte après la commutation. Pour 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 avez l'habitude AWS Backup de gérer des sauvegardes automatisées des ressources dans un déploiement bleu/vert, ajustez la ressource IDs utilisée AWS Backup après le passage au numérique. Pour de plus amples informations, veuillez consulter Utilisation AWS Backup pour gérer les sauvegardes automatisées pour Amazon RDS.

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

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

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

    Pour de plus amples informations, veuillez consulter Restauration d'une instance de base de données à une heure spécifiée pour Amazon RDS.

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

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

  • Lorsque vous supprimez une instance de base de données dans l'environnement écologique 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 Amazon Resource Name (ARN) que l'instance de base de données supprimée, elle a une valeur DbiResourceId différente, de sorte qu'elle ne fait pas partie de l'environnement vert.

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

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

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

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