Bonnes pratiques pour les déploiements bleu/vert d'Amazon RDS - Amazon Relational Database Service
Bonnes pratiques générales pour les déploiements bleu/vertRDS pour MySQL MySQL : bonnes pratiques pour les déploiements bleu/vertMeilleures pratiques de RDS pour 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 déploiements bleu/vert d'Amazon RDS

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 les instances de base de données 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 déploiement bleu/vert 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'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.

    Note

    Cette limitation ne s'applique pas aux déploiements bleu/vert de RDS pour PostgreSQL qui utilisent la réplication physique. Pour de plus amples informations, veuillez consulter Limitations de RDS pour PostgreSQL pour les déploiements bleu/vert avec réplication physique.

  • Après avoir créé le déploiement bleu/vert, gérez le chargement différé si nécessaire. Assurez-vous que le chargement des données est terminé avant de basculer. Pour de plus amples informations, veuillez consulter Chargement différé et initialisation du stockage pour les déploiements bleu/vert.

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

RDS pour MySQL MySQL : 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 Aurora MySQL d'une instance de base de données RDS .

  • Évitez d'utiliser des moteurs de stockage non transactionnels, tels que MyISAM, qui ne sont pas optimisés pour la réplication.

  • Optimisez les répliques de lecture et l'environnement écologique pour la réplication des journaux binaires. Si votre moteur de base de données le prend en charge, activez la réplication GTID, parallel et crash-safe pour garantir la cohérence et la durabilité des données avant de créer votre déploiement bleu/vert. Pour de plus amples informations, veuillez consulter Utilisation de GTID la réplication basée.

  • Si l'environnement vert connaît un retard de réplication, tenez compte des points suivants :

    • Définissez temporairement le innodb_flush_log_at_trx_commit paramètre 2dans 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 d'1avant le basculement. Si un arrêt ou un crash inattendu survient avec la valeur du paramètre temporaire, reconstruisez l'environnement écologique pour éviter toute corruption de données non détectée.

    • Pour réduire la latence d'écriture et améliorer le débit de réplication, remplacez temporairement les instances de base de données multi-AZ vertes par des instances de base de données mono-AZ. Réactivez Multi-AZ juste avant le passage au numérique.

Meilleures pratiques de RDS pour PostgreSQL pour les déploiements bleu/vert

Tenez compte des meilleures pratiques suivantes lorsque vous créez un déploiement bleu/vert à partir d'une instance de base de données RDS pour PostgreSQL.

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

Tenez compte des meilleures pratiques générales suivantes lorsque vous créez un déploiement bleu/vert à partir d'une instance de base de données RDS pour PostgreSQL.

  • 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 SQL extensions Postgre RDS pour les bases de données SQL Postgre.

  • 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 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 les versions 12 et supérieures de PostgreSQL, désactivez index_cleanup le paramètre sur les tables volumineuses ou occupées afin d'augmenter le taux de maintenance normale sur les bases de données bleues. Pour de plus amples informations, veuillez consulter Mise à vide d'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.

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

  • Pour éviter que les segments du journal d'écriture anticipée (WAL) ne soient supprimés de l'environnement bleu, définissez le wal_keep_segments paramètre sur 15625 pour PostgreSQL version 13 ou inférieure. Pour les versions 14 et supérieures, définissez le wal_keep_size paramètre sur 1 TiB, s'il y a suffisamment d'espace de stockage disponible.

Meilleures pratiques de RDS pour PostgreSQL pour les déploiements bleu/vert avec réplication physique

Avec la réplication physique, Amazon RDS crée une réplique en lecture de l'instance de base de données source. Pour les paramètres associés, la surveillance, le réglage et le dépannage, consultezUtilisation de réplicas en lecture pour Amazon RDS for PostgreSQL.

Pour savoir dans quels cas les déploiements bleu/vert utilisent la réplication physique au lieu de la réplication logique, consultez. Méthodes de SQL réplication Postgre pour les déploiements bleu/vert

Meilleures pratiques de RDS pour PostgreSQL pour les déploiements bleu/vert avec réplication logique

Tenez compte des meilleures pratiques suivantes lorsque vous créez un blue/green deployment that uses logical replication. For an explanation of when blue/green déploiement qui utilise la réplication logique plutôt que la réplication physique, voirMéthodes de SQL réplication Postgre pour les déploiements bleu/vert.

  • 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. Pour de plus amples informations, veuillez consulter la documentation sur PostgreSQL.

    • 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 Mesures au CloudWatch niveau de l'instance Amazon pour Amazon RDS.

    • Dans les versions 14 et supérieures de RDS pour PostgreSQL, vous pouvez surveiller la taille des fichiers de dépassement logique à l'aide de la vue système. pg_stat_replication_slots

  • Si vous utilisez l'aws_s3extension, donnez à l'instance de base de données verte 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, veuillez consulter Configuration de l'accès à un compartiment Amazon S3.

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

  • 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 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, consultezComment effectuer une mise à niveau de version majeure RDS pour Postgre SQL.

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