Bonnes pratiques pour les déploiements bleu/vert

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.

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

  Note

  Cette limitation ne s'applique pas aux RDS déploiements SQL bleu/vert Postgre qui utilisent la réplication physique. Pour de plus amples informations, veuillez consulter RDSpour les SQL limitations de Postgre 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.

RDSpour My SQL meilleures 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 Aurora My SQL DB RDS pour .

• É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 chargeGTID, activez la réplication en parallèle et en toute sécurité 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 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 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.

RDSpour les SQL meilleures pratiques de Postgre 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.

Rubriques

• RDSpour les meilleures pratiques SQL générales de Postgre pour les déploiements bleu/vert
• RDSpour les SQL meilleures pratiques de Postgre pour les déploiements bleu/vert avec réplication physique
• RDSpour les SQL meilleures pratiques de Postgre pour les déploiements bleu/vert avec réplication logique

RDSpour les meilleures pratiques SQL générales de Postgre 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 Postgre RDS pour PostgreSQL.

• 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 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 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. 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 empêcher les segments write-ahead log (WAL) d'être supprimés de l'environnement bleu, définissez le wal_keep_segments paramètre sur 15625 pour les SQL versions 13 et antérieures de Postgre. 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.

RDSpour les SQL meilleures pratiques de Postgre 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épliques de lecture pour Amazon RDS pour Postgre SQL.

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

RDSpour les SQL meilleures pratiques de Postgre 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 plus d'informations, consultez la SQLdocumentation Postgre.

  • 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 RDS les SQL versions 14 et supérieures de Postgre, vous pouvez surveiller la taille des fichiers de dépassement logique à l'aide de la vue pg_stat_replication_slots système.

• Si vous utilisez l'aws_s3extension, donnez à l'instance 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.

• Passez en revue les performances de vos DELETE instructions UPDATE and et déterminez si la création d'un index sur la colonne utilisée dans la WHERE clause 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.