Bonnes pratiques pour les (Amazon Aurora blue/green ) - Amazon Aurora
Bonnes pratiques générales pour les blue/green déploiements : bonnes pratiques pour les déploiements blue/green Meilleures pratiques d'Aurora PostgreSQL pour les déploiements blue/green Bonnes pratiques relatives à la base de données globale Aurora pour les déploiements blue/green

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 (Amazon Aurora blue/green )

Les meilleures pratiques pour les blue/green déploiements sont les suivantes.

Bonnes pratiques générales pour les blue/green déploiements

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

  • Si vous utilisez un blue/green déploiement pour implémenter des modifications de schéma, apportez uniquement 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 passez d'un blue/green déploiement à un autre, suivez les meilleures pratiques en la matière. Pour de plus amples informations, veuillez consulter Bonnes pratiques de bascule.

 : bonnes pratiques pour les déploiements blue/green

Tenez compte des meilleures pratiques suivantes lorsque vous créez un blue/green déploiement à partir d'un cluster de base 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é.

Meilleures pratiques d'Aurora PostgreSQL pour les déploiements blue/green

Tenez compte des meilleures pratiques suivantes lorsque vous créez un blue/green déploiement à partir d'un cluster de base 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 de plus amples informations, veuillez consulter 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 ReplicationSlotDiskUsage CloudWatch métrique. 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 FreeableMemory CloudWatch métrique. Pour de plus amples informations, veuillez consulter 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 dernière version avant de créer un déploiement. blue/green Pour de plus amples informations, veuillez consulter 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 manuelle de congélation sous vide sur les tables occupées avant de créer le blue/green déploiement. 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. Il est recommandé d'utiliser cette approche uniquement lors d'un blue/green déploiement. 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.

Bonnes pratiques relatives à la base de données globale Aurora pour les déploiements blue/green

Outre les meilleures pratiques générales et spécifiques au moteur répertoriées ci-dessus, tenez compte des meilleures pratiques suivantes pour l' Global Database.

  • Surveillez les CloudWatch indicateurs suivants pour identifier les périodes de faible activité dans votre environnement de production :

    • DatabaseConnections

    • ActiveTransactions

    Planifiez le blue/green passage au numérique pendant votre période de maintenance planifiée ou pendant une période de faible activité.

  • Blue/Green switchover duration varies based on your workload and the number of secondary regions. When you initiate a blue/greenlors du basculement, le service attend que le délai de réplication atteigne zéro avant de poursuivre. Nous vous recommandons de vérifier le délai de réplication avant de lancer un changement.

  • Si vous avez l'intention d'utiliser un paramètre de base de données ou un groupe de paramètres de cluster de base de données autre que celui par défaut pour votre environnement écologique, créez le groupe de paramètres souhaité portant le même nom dans toutes les régions secondaires avant de lancer le blue/green déploiement.