Considérations et limites relatives aux déploiements bleu/vert

Amazon RDS suit les ressources dans le cadre de déploiements bleu/vert avec la fin DbiResourceId 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 base de données :

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 les ressources vertes sont présentées comme 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 promues 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 la ressource RDS API etIDs, ajustez la ressource IDs utilisée lors du filtrage après le passage au mode de commutation.

• 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 les Performances InsightsAPI, ajustez la ressource IDs dans les appels 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 IAM les politiques, assurez-vous d'ajouter la ressource IDs des ressources récemment promues lorsque cela est nécessaire. Pour de plus amples informations, veuillez consulter Identity and Access Management pour Amazon RDS.

• Si IAM des rôles 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 d'instances de IAMbase de données à l'aide de l'authentification de base de données, assurez-vous que la IAM politique utilisée pour l'accès à la base de données comporte à la fois les bases de données bleues et vertes répertoriées sous l'Resourceélément de la stratégie. 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.

• 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 date spécifiée.

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

• Lorsque vous supprimez une instance de base de données dans l'environnement vert d'un déploiement bleu/vert, vous ne pouvez pas créer une nouvelle instance de base de données pour la remplacer dans le déploiement bleu/vert.

  Si vous créez une nouvelle instance de base de données portant le même nom et le même nom de ressource Amazon (ARN) que l'instance de base de données suppriméeDbiResourceId, elle est différente et ne fait donc pas partie de l'environnement écologique.

  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.

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.

• Pendant le passage au numérique, les environnements bleu et vert ne peuvent pas avoir d'ETLintégrations nulles 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 :

  • RDSProxy Amazon

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

SQLLimites d'for My pour les déploiements bleu/vert

Les restrictions suivantes s'appliquent aux déploiements My SQL blue/green :

• Mes SQL versions 8.0.11 à 8.0.13 présentent un bogue communautaire qui les empêche de prendre en charge les déploiements bleu/vert.

• 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 sont pas compatibles avec AWS JDBC Driver for My. SQL Pour plus d'informations, consultez la section Limitations connues sur GitHub.

SQLLimitations d'pour Postgre pour les déploiements bleu/vert

Les limitations suivantes s'appliquent aux déploiements SQL bleu/vert de Postgre :

• Les versions suivantes d' sont prises en charge en tant que versions source et cible de mise à niveau : 11.21 et versions ultérieures, 12.16 et versions ultérieures, 13.12 et versions ultérieures, 14.9 et versions ultérieures, et 15.4 et versions ultérieures. Pour les versions antérieures, vous pouvez mettre à niveau une version mineure vers une version prise en charge.

• 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 autogérée (éditeur) ou une réplique (abonné).

• Si le de base de données bleu est configuré en tant que serveur étranger d'une extension de wrapper (FDW) étrangère, vous devez utiliser le nom du point de terminaison du d'instances au lieu des adresses IP. Ainsi, la configuration reste fonctionnelle après la commutation.

• L'extension pg_partman doit être désactivée dans l'environnement bleu lorsque vous créez un déploiement bleu/vert. L'extension effectue DDL des opérations telles que CREATE TABLE celles 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 pg_active doivent être désactivées dans l'environnement bleu lorsque vous créez un déploiement bleu/vert. Après avoir fait de l'environnement écologique 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.

Limites de réplication SQL logique Postgre pour les déploiements bleu/vert

Les déploiements bleu/vert utilisent la réplication logique pour synchroniser l'environnement intermédiaire avec l'environnement de production. Postgre SQL impose certaines restrictions liées à la réplication logique, qui se traduisent par des limitations lors de la création de déploiements bleu/vert pour les RDSclusters de . SQL

Le tableau suivant décrit les limites de réplication logique qui s'appliquent aux déploiements bleu/vert pour . SQL

Limitation	Explication
Les instructions du langage de définition des données (DDL), telles que CREATE TABLE etCREATE SCHEMA, ne sont pas répliquées de l'environnement bleu vers l'environnement vert.	Si Amazon RDS détecte un DDL changement dans l'environnement bleu, vos bases de données vertes entrent dans un état de réplication dégradé. Vous recevez un événement vous informant que les DDL modifications apportées à l'environnement bleu ne peuvent pas être reproduites dans l'environnement vert. Vous devez supprimer le déploiement bleu/vert et toutes les bases de données vertes, puis le recréer. Dans le cas contraire, vous ne parviendrez pas à basculer vers le déploiement bleu/vert.
Les opérations NEXTVAL sur les objets de séquence ne sont pas synchronisées entre l'environnement bleu et l'environnement vert.	Pendant le passage au numérique, Aurora incrémente les valeurs de séquence dans l'environnement vert pour qu'elles correspondent à 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 la création ou la modification d'objets volumineux dans l'environnement bleu qui sont stockés dans la table pg_largeobject système, vos bases de données vertes entrent dans un état de réplication dégradé. RDS génère un événement vous avertissant que les modifications d'objets de grande taille dans l'environnement bleu ne peuvent pas être répliquées dans l'environnement vert. Vous devez supprimer le déploiement bleu/vert et toutes les bases de données vertes, puis le recréer. Dans le cas contraire, vous ne parviendrez pas à basculer vers le déploiement bleu/vert.
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 REFRESHMATERIALIZEDVIEWcommande ou planifier une actualisation.
UPDATEet DELETE les opérations 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 de l'instance de base de données possèdent une clé primaire.

Pour plus d'informations, consultez la section Restrictions dans la documentation de réplication SQL logique Postgre.