Bonnes pratiques Amazon Aurora pour les déploiements bleu/vert - Amazon Aurora
Bonnes pratiques générales pour les déploiements bleu/vertBonnes pratiques Aurora MySQL pour les déploiements bleu/vertBonnes pratiques Aurora PostgreSQL pour les déploiements bleu/vert

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 Amazon Aurora pour les déploiements bleu/vert

Voici les bonnes pratiques pour les déploiements bleu/vert :

Bonnes pratiques générales pour les déploiements bleu/vert

Tenez compte des bonnes pratiques générales suivantes lorsque vous créez un déploiement bleu/vert.

  • Testez minutieusement le cluster de bases 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 bascule.

  • Si 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’une table sans interrompre la réplication du déploiement bleu vers 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 Replication with Differing Table Definitions on Source and Replica dans la documentation MySQL, et Restrictions dans la documentation Réplication logique PostgreSQL.

  • 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 un déploiement bleu/vert, suivez les bonnes pratiques de bascule. Pour plus d’informations, consultez Bonnes pratiques de bascule.

Bonnes pratiques Aurora MySQL pour les déploiements bleu/vert

Tenez compte des bonnes pratiques suivantes lorsque vous créez un déploiement bleu/vert à partir d’un cluster de bases de données Aurora MySQL.

  • Si l’environnement vert connaît un retard de réplica, tenez compte des éléments suivants :

    • Désactivez la conservation des journaux binaires si elle n’est pas nécessaire, ou désactivez-la temporairement jusqu’à ce que la réplication rattrape son retard. Pour ce faire, redéfinissez le paramètre du cluster de bases de données binlog_format sur 0 et redémarrez l’instance de base de données d’enregistreur verte.

    • Définissez temporairement le paramètre innodb_flush_log_at_trx_commit sur 0 dans le groupe de paramètres de base de données vert. Une fois que la réplication a rattrapé son retard, revenez à la valeur par défaut de 1 avant la bascule. Si un arrêt ou un incident inattendu survient avec la valeur du paramètre temporaire, reconstruisez l’environnement vert pour éviter toute corruption de données non détectée. Pour plus d’informations, consultez Configuration de la fréquence à laquelle le tampon du journal est vidé.

Bonnes pratiques Aurora PostgreSQL pour les déploiements bleu/vert

Tenez compte des bonnes pratiques suivantes lorsque vous créez un déploiement bleu/vert à partir d’un cluster de bases de données Aurora PostgreSQL.

  • Surveillez le cache d’écriture simultanée de la réplication logique Aurora PostgreSQL et modifiez la mémoire tampon du cache si nécessaire. Pour plus d’informations, consultez Surveillance du cache à écriture simultanée de la réplication logique Aurora PostgreSQL.

  • Augmentez la valeur du paramètre de base de données logical_decoding_work_mem 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. Pour plus d’informations, consultez Ajustement de la mémoire de travail pour le décodage logique.

    • Vous pouvez surveiller le dépassement des transactions écrites sur le disque à l’aide de la métrique CloudWatch ReplicationSlotDiskUsage. Cette métrique fournit des informations sur l’utilisation des emplacements de réplication sur le disque, ce qui permet d’identifier les cas où les données de transaction dépassent la capacité de mémoire et sont stockées sur disque. Vous pouvez surveiller la mémoire disponible à l’aide de la métrique FreeableMemory de CloudWatch. Pour plus d’informations, consultez Métriques de niveau instance pour Amazon Aurora.

    • Dans Aurora PostgreSQL versions 14 et ultérieures, vous pouvez surveiller la taille des fichiers de dépassement logique à l’aide de la vue système pg_stat_replication_slots.

  • Mettez à jour toutes vos extensions PostgreSQL vers la version la plus récente avant de créer un déploiement bleu/vert. Pour plus d’informations, consultez Mise à niveau des extensions PostgreSQL.

  • Si vous utilisez l’extension aws_s3, autorisez le cluster de bases de données vert à accéder à Amazon S3 via un rôle IAM une fois l’environnement vert créé. Cela permet aux commandes d’importation et d’exportation de continuer à fonctionner après la bascule. 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 vert, exécutez l’opération ANALYZE sur toutes les bases de données pour actualiser la table pg_statistic. 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 bonnes pratiques supplémentaires lors des mises à niveau des versions majeures, consultez Réalisation d’une mise à niveau de version majeure.

  • Évitez de configurer les déclencheurs comme ENABLE REPLICA ou ENABLE ALWAYS si 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éplica important. Pour réduire le retard de réplica, envisagez les opérations suivantes :

    • Réduisez les transactions de longue durée et les sous-transactions qui peuvent être retardées jusqu’à ce que l’environnement vert rattrape l’environnement bleu.

    • Réduisez les opérations en bloc dans l’environnement bleu jusqu’à ce que l’environnement vert rattrape l’environnement bleu.

    • Lancez une opération de gel manuel du processus vacuum sur les tables occupées avant de créer le déploiement bleu/vert. Pour obtenir des instructions, consultez Réalisation d’un gel manuel du processus vacuum.

    • Dans PostgreSQL versions 12 et ultérieures, désactivez le paramètre index_cleanup sur les tables volumineuses ou occupées afin d’améliorer l’efficacité de la maintenance régulière des bases de données bleues. Pour plus d’informations, consultez Vidage d’une table le plus rapidement possible.

      Note

      Le fait de ne pas nettoyer régulièrement l’index pendant l’opération de vacuum peut entraîner un gonflement de l’index, ce qui peut dégrader les performances d’analyse. Une bonne pratique consiste à utiliser cette approche uniquement lors d’un déploiement bleu/vert. Une fois le déploiement terminé, nous vous recommandons de reprendre la maintenance et le nettoyage réguliers de l’index.

    • Un retard de réplica peut se produire si les instances de base de données bleues et vertes sont sous-dimensionnées par rapport à la charge de travail. Assurez-vous que vos instances de base de données n’atteignent pas leurs limites de ressources pour le type d’instance. Pour plus d’informations, consultez Utilisation des CloudWatch métriques Amazon pour analyser l'utilisation des ressources pour Aurora PostgreSQL.

  • 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 en réglant le paramètre wal_sender_timeout sur 0 dans l’environnement bleu et le paramètre wal_receiver_timeout sur 0 dans l’environnement vert.

  • Vérifiez les performances de vos instructions UPDATE et DELETE et déterminez si la création d’un index sur la colonne utilisée dans la clause WHERE peut optimiser ces requêtes. Cela peut améliorer les performances lorsque les opérations sont réexécutées dans un environnement vert. Pour plus d’informations, consultez Vérifiez les filtres de prédicat pour détecter les requêtes qui génèrent des attentes.

  • Si vous utilisez des déclencheurs, assurez-vous qu’ils n’interfèrent pas avec la création, la mise à jour et la suppression d’objets pg_catalog.pg_publication, pg_catalog.pg_subscription et pg_catalog.pg_replication_slots dont le nom commence par « rds ».

  • Si Babelfish est activé sur le cluster de bases de données source, les paramètres suivants doivent avoir les mêmes paramètres dans le groupe de paramètres du cluster de bases de données cible pour l’environnement vert que dans le groupe de paramètres du cluster de bases 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.