Limites et considérations relatives aux déploiements Amazon RDS ( blue/green ) - Amazon Relational Database Service
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 déploiements Amazon RDS ( 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 :

  • 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 dédié aux journaux (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éplicas en lecture.

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

  • 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. En outre, vous ne pouvez pas transformer une instance de base de données chiffrée en instance de base de données non chiffrée.

  • Vous ne pouvez pas transmettre une instance de base de données bleue vers une version de moteur supérieure à celle de son instance de base de données verte correspondante.

  • 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

    • 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 blue/green

Les limitations suivantes s'appliquent aux blue/green déploiements RDS pour MySQL :

  • L’instance de base de données bleue ne peut pas être un réplica 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 de mise à niveau de version majeure lors de la création du blue/green déploiement.

    Dans ce cas, vous pouvez créer un blue/green déploiement sans spécifier de mise à niveau de version majeure. Ensuite, vous pouvez mettre à niveau la base de données dans l’environnement vert. Pour plus d’informations, consultez 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 blue/green de RDS pour PostgreSQL pour les déploiements avec réplication physique

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

  • Une fois l’environnement vert créé, vous ne pouvez pas effectuer de mise à niveau manuelle de 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 (diffuseur de publication) ou un réplica (abonné).

  • Les déploiements bleu/vert présentent les limitations suivantes lors de la configuration de la réplication différée dans RDS pour PostgreSQL :

    • Instance source verte : recovery_min_apply_delay parameter n’est pas pris en compte, même s’il est configuré dans le groupe de paramètres. Aucun paramètre de délai sur l’instance source verte ne prend effet.

    • Instance de réplica verte : recovery_min_apply_delay parameter est entièrement pris en charge et appliqué au fichier de configuration PostgreSQL. Les paramètres de délai fonctionnent comme prévu pendant le flux de travail de bascule.

    • La réplication différée n'est pas compatible avec les Blue/Green déploiements RDS pour les mises à niveau de versions majeures.

Limitations d' RDS pour PostgreSQL pour les déploiements avec réplication logique blue/green

Les limitations suivantes s’appliquent aux déploiements bleu/vert RDS pour PostgreSQL qui utilisent la réplication logique. Pour savoir dans quels cas blue/green les déploiements utilisent la réplication logique au lieu de la réplication physique, consultezMéthodes de réplication PostgreSQL pour les déploiements bleu/vert.

  • Les tables non journalisées ne sont pas répliquées dans l’environnement vert,.

  • L’instance de base de données bleue ne peut pas être une source logique (diffuseur de publication) ou un réplica (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 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 de l’instance de base 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 le cluster source.

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

  • Les déploiements bleu/vert présentent les limitations suivantes lors de la configuration de la réplication différée dans RDS pour PostgreSQL :

    • Instance source verte : recovery_min_apply_delay parameter n’est pas pris en compte, même s’il est configuré dans le groupe de paramètres. Aucun paramètre de délai sur l’instance source verte ne prend effet.

    • Instance de réplica verte : recovery_min_apply_delay parameter est entièrement pris en charge et appliqué au fichier de configuration PostgreSQL. Les paramètres de délai fonctionnent comme prévu pendant le flux de travail de bascule.

    • La réplication différée n'est pas compatible avec les Blue/Green déploiements RDS pour les mises à niveau de versions majeures.

  • La création de partitions sur des tables partitionnées n’est pas prise en charge lors des déploiements bleu/vert pour RDS pour PostgreSQL. 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.

    • 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

PostgreSQL impose certaines restrictions liées à la réplication logique, qui se traduisent par des limitations lors de la création de blue/green déploiements pour les clusters de bases de données .

Le tableau suivant décrit les limitations de réplication logique qui s’appliquent aux déploiements bleu/vert pour RDS pour 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 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 Amazon RDS PostgreSQL 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, 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 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 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 blue/green déploiement et toutes les bases de données vertes, puis les 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 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 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 d’instance 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 (ID d'instance) 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’une instance de base de données peut être mydb dans l’environnement bleu. Après la bascule, 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 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 RDS dansAWS 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 la base de données avec Performance Insights sur Amazon RDS.

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

  • Si des rôles IAM sont associés à votre instance de base 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 instance à 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 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 de AWS Backup pour gérer les sauvegardes automatiques pour Amazon RDS.

  • Si vous souhaitez restaurer un instantané de base de données manuel ou automatique pour une instance de base de données faisant partie d'un blue/green déploiement, assurez-vous de restaurer le cliché de base de données correct en examinant l'heure à laquelle le cliché a été pris. Pour de plus amples informations, veuillez consulter Restauration d’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 bascule, vous ne pouvez pas utiliser son nom précédent pour les opérations DescribeDBInstanceAutomatedBackups ou RestoreDBInstanceToPointInTime.

    Pour plus d’informations, consultez Restauration d’une instance de base de données à un instant précis 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 bascule.

  • 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 déploiement, vous ne pouvez pas créer une nouvelle instance de base de données pour la remplacer dans le 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 bascule.

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

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