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.
Bonnes pratiques pour les déploiements bleu/vert
Les meilleures pratiques pour les déploiements bleu/vert sont les suivantes.
Bonnes pratiques d'ordre général
-
Testez minutieusement le cluster de base de données Aurora dans l'environnement vert avant le basculement.
-
Gardez vos bases de données dans l'environnement vert en lecture seule. Nous vous recommandons d'activer les opérations d'écriture sur l'environnement vert avec prudence, car elles peuvent entraîner des conflits de réplication. Elles peuvent également entraîner la présence de données involontaires dans les bases de données de production après la commutation.
-
Lorsque vous utilisez un déploiement bleu/vert pour la mise en œuvre de modifications de schémas, n'effectuez que des modifications compatibles avec la réplication.
Par exemple, vous pouvez ajouter de nouvelles colonnes à la fin d'un tableau sans perturber la réplication entre le déploiement bleu et le déploiement vert. Toutefois, les modifications de schéma, telles que le renommage de colonnes ou de tables, interrompent la réplication vers le déploiement vert.
Pour plus d'informations sur les modifications compatibles avec la réplication, consultez Réplication avec des définitions de table différentes sur la source et la réplique
dans la section Ma SQL documentation et Restrictions dans la documentation de réplication SQL logique Postgre. -
Utilisez le point de terminaison du cluster, le point de terminaison de lecture ou le point de terminaison personnalisé pour toutes les connexions dans les deux environnements. N'utilisez pas de points de terminaison d'instance ou de points de terminaison personnalisés avec des listes statiques ou d'exclusion.
-
Lorsque vous basculez vers un déploiement bleu/vert, suivez les bonnes pratiques de commutation. Pour de plus amples informations, veuillez consulter Bonnes pratiques de commutation.
Aurora Postgre SQL
-
Surveillez le cache d'écriture directe de réplication SQL logique Aurora Postgre et ajustez la mémoire tampon du cache si nécessaire. Pour de plus amples informations, veuillez consulter Surveillance du cache d'écriture directe de réplication SQL logique Aurora Postgre.
-
Si votre base de données dispose de suffisamment de mémoire libre, augmentez la valeur du paramètre
logical_decoding_work_mem
DB dans l'environnement bleu. Cela permet de réduire le nombre de décodages sur disque et d'utiliser de la mémoire à la place. Vous pouvez surveiller la mémoire disponible à l'aide de laFreeableMemory
CloudWatch métrique. Pour de plus amples informations, veuillez consulter CloudWatch Métriques Amazon pour Amazon Aurora. -
Mettez à jour toutes vos SQL extensions Postgre vers la dernière version avant de créer un déploiement bleu/vert. Pour de plus amples informations, veuillez consulter Mise à niveau des extensions Postgre SQL.
-
Si vous utilisez l'
aws_s3
extension, assurez-vous de donner au cluster de base de données d' de base de données verte l'accès à Amazon S3 via un IAM rôle une fois l'environnement vert créé. Cela permet aux commandes d'importation et d'exportation de continuer à fonctionner après la commutation. Pour obtenir des instructions, consultez Configuration de l'accès à un compartiment Amazon S3. -
Si vous spécifiez une version du moteur supérieure pour l'environnement écologique, exécutez l'
ANALYZE
opération sur toutes les bases de données pour actualiser lepg_statistic
tableau. Les statistiques de l'optimiseur ne sont pas transférées lors d'une mise à niveau de version majeure. Vous devez donc régénérer toutes les statistiques pour éviter les problèmes de performances. Pour connaître les meilleures pratiques supplémentaires lors des mises à niveau majeures des versions, consultez . -
Évitez de configurer les déclencheurs au fur
ENABLE REPLICA
ENABLE ALWAYS
et à mesure que le déclencheur est utilisé sur la source pour manipuler des données. Dans le cas contraire, le système de réplication propage les modifications et exécute le déclencheur, ce qui entraîne une duplication. -
Les transactions de longue durée peuvent entraîner un retard de réplication important. Pour réduire le délai de réplication, envisagez de procéder comme suit :
-
Réduisez les transactions de longue durée qui peuvent être retardées jusqu'à ce que l'environnement vert rattrape l'environnement bleu.
-
Lancez une opération manuelle de congélation sous vide sur les tables occupées avant de créer le déploiement bleu/vert.
-
Pour les SQL versions 12 et supérieures de Postgre, désactivez le
index_cleanup
paramètre sur les tables volumineuses ou occupées afin d'augmenter le taux de maintenance normale sur les bases de données bleues.
-
-
Une réplication lente peut entraîner des redémarrages fréquents des expéditeurs et des destinataires, ce qui retarde la synchronisation. Pour vous assurer qu'ils restent actifs, désactivez les délais d'expiration
0
en réglant lewal_sender_timeout
paramètre sur l'environnement bleu et lewal_receiver_timeout
paramètre sur0
l'environnement vert. -
Si Babelfish est activé sur le cluster de base de données source, les paramètres suivants doivent avoir les mêmes paramètres dans le groupe de paramètres du cluster de base de données cible pour l'environnement vert que dans le groupe de paramètres du cluster de base de données source :
-
rds.babelfish_status
-
babelfishpg_tds.tds_default_numeric_precision
-
babelfishpg_tds.tds_default_numeric_scale
-
babelfishpg_tsql.default_locale
-
babelfishpg_tsql.migration_mode
-
babelfishpg_tsql.server_collation_name
Pour obtenir plus d'informations sur ces paramètres, consultez Paramètres du groupe de paramètres de cluster de bases de données pour Babelfish.
-