View a markdown version of this page

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 )

Blue/green les déploiements 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 relatives aux blue/green déploiements

Les limitations générales suivantes s'appliquent aux blue/green déploiements :

  • Blue/green les déploiements 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.

  • Si vous utilisez le proxy Amazon RDS, vous devez enregistrer votre cluster bleu auprès du proxy avant de créer un blue/green déploiement. Si un blue/green déploiement existe déjà pour un cluster bleu donné, l'enregistrement de ce cluster bleu auprès du proxy Amazon RDS sera bloqué.

  • Le proxy Amazon RDS avec blue/green déploiements n'est pas pris en charge pour les bases de données mondiales Aurora.

  • Blue/green les déploiements ne sont pas pris en charge pour les fonctionnalités suivantes :

    • Réplicas en lecture en cascade

    • Cross-Region lire des répliques

    • CloudFormation

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

      Blue/green les déploiements sont pris en charge pour les déploiements d' Multi-AZ instances de base de données. Pour plus d'informations sur les Multi-AZ déploiements, consultezConfiguration et gestion d'un Multi-AZ déploiement 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 d'une version du moteur d'une instance de base de données.

  • Blue/green les déploiements 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 blue/green.

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

  • Blue/green les déploiements qui utilisent la réplication physique ne prennent pas en charge les modifications de schéma dans l'environnement écologique, 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é).

  • Blue/Green les déploiements présentent les limites 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 à RDS pour les déploiements PostgreSQL qui utilisent la réplication blue/green 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 blue/green.

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

  • Blue/Green les déploiements présentent les limites 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 nouvelles partitions sur des tables partitionnées n'est pas prise en charge lors blue/green des déploiements d' 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 limites de réplication logique qui s'appliquent aux blue/green déploiements d'. 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. Alors qu'un volume élevé de séquences permet généralement le passage au numérique, un nombre exceptionnellement élevé, tel que plusieurs centaines de milliers, peut entraîner l'expiration du processus avant d'être terminé. Vous pouvez augmenter le délai de basculement pour laisser plus de temps à la synchronisation. Pour de plus amples informations, veuillez consulter Délai de 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 basculez les ressources vertes pour en faire les nouvelles ressources de production, leurs identifiants ne correspondent pas aux identifiants des ressources bleues qui étaient précédemment en production.

Après avoir transféré un blue/green déploiement, pensez à mettre à jour les identifiants des ressources pour les remplacer par ceux des ressources de production récemment transférées pour les fonctionnalités et 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 RDS et des identifiants de ressources, ajustez les identifiants de ressources utilisés dans le filtrage après la bascule.

  • Si vous l'utilisez CloudTrail pour auditer des ressources, ajustez les consommateurs de CloudTrail afin de suivre les nouveaux identifiants de ressources après le passage au numérique. Pour de plus amples informations, veuillez consulter Surveillance des appels AWS CloudTrail.

  • Si vous utilisez l’API Performance Insights, ajustez les ID des ressources dans les appels à l’API après la bascule. Pour plus d’informations, consultez 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 identifiants de ressources dans les politiques IAM, veillez à ajouter les identifiants des ressources nouvellement transférées lorsque cela est nécessaire. Pour plus d’informations, consultez 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 le cadre d'un blue/green déploiement, ajustez les identifiants de ressources utilisés 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 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 de plus amples informations, veuillez consulter Restauration d’une instance de base de données à un instant précis pour Amazon RDS.

  • Lorsque vous ajoutez une réplique en lecture à une instance de base de données dans l'environnement vert d'un blue/green déploiement, la nouvelle réplique en lecture ne remplacera pas une réplique en lecture dans l'environnement bleu lorsque vous passez à un autre. 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 Amazon RDS.