Bonnes pratiques pour les Amazon Aurora - Amazon Aurora
Bonnes pratiques générales pour les déploiements bleu/vert : bonnes pratiques pour les déploiements bleu/vertMeilleures pratiques d'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 pour les Amazon Aurora

Les meilleures pratiques pour les déploiements bleu/vert sont les suivantes.

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

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

  • 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 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 vers un déploiement bleu/vert, suivez les bonnes pratiques de commutation. Pour de plus amples informations, veuillez consulter Bonnes pratiques de commutation.

 : bonnes pratiques pour les déploiements bleu/vert

Tenez compte des meilleures pratiques suivantes lorsque vous créez un déploiement bleu/vert à partir d'un cluster de base de données for MySQL.

  • Si l'environnement vert connaît un retard de réplication, tenez compte des points 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 soit rattrapée. Pour ce faire, redéfinissez le paramètre du cluster de binlog_format base de données sur l'instance de base de données Green Writer 0 et redémarrez l'instance de base de données Green Writer.

    • Définissez temporairement le innodb_flush_log_at_trx_commit paramètre sur 1 dans le groupe de paramètres DB vert. Une fois que la réplication a rattrapé son retard, revenez aux valeurs par défaut avant le basculement. Si un arrêt ou un crash inattendu survient avec les valeurs des paramètres temporaires, reconstruisez l'environnement écologique pour éviter toute corruption de données non détectée. Pour de plus amples informations, veuillez consulter Configuration de la fréquence à laquelle le tampon du journal est vidé.

Meilleures pratiques d'Aurora PostgreSQL pour les déploiements bleu/vert

Tenez compte des meilleures pratiques suivantes lorsque vous créez un déploiement bleu/vert à 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 de plus amples informations, veuillez consulter Surveillance du cache d'écriture directe de réplication SQL logique Aurora Postgre.

  • 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. 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 version 14 et versions 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 de plus amples informations, veuillez consulter Mise à niveau des extensions Postgre SQL.

  • Si vous utilisez l'aws_s3extension, accordez au cluster de base de données vert l'accès à 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 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'ANALYZEopération sur toutes les bases de données pour actualiser le pg_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, consultezExécution d'une mise à niveau de version majeure.

  • É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, pensez à effectuer 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 vrac 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 déploiement bleu/vert. Pour obtenir des instructions, reportez-vous à la section Réalisation d'une congélation sous vide manuelle.

    • Dans les versions 12 et supérieures de PostgreSQL, désactivez index_cleanup le paramètre 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, voir Passer l'aspirateur sur une table le plus rapidement possible.

      Note

      Le fait de ne pas nettoyer régulièrement l'index pendant que vous passez l'aspirateur peut entraîner un gonflement de l'index, ce qui peut dégrader les performances de numérisation. Il est recommandé d'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 décalage de réplication 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 de plus amples informations, veuillez consulter Utilisation des CloudWatch métriques Amazon pour analyser l'utilisation des ressources pour Aurora PostgreSQL.

  • La lenteur de la réplication 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 le wal_sender_timeout paramètre sur l'environnement bleu et le wal_receiver_timeout paramètre sur 0 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 rejouées dans un environnement vert. Pour de plus amples informations, veuillez consulter 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'pg_catalog.pg_publicationpg_catalog.pg_replication_slotsobjets dont le nom commence par « rds ». pg_catalog.pg_subscription

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