Meilleures pratiques pour Amazon RDS blue/green déploiements

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

Après avoir créé le blue/green déploiement, 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 blue/green déploiements.

Lorsque vous réduisez l'espace de stockage alloué lors d'un blue/green déploiement, suivez les instructions relatives au dimensionnement du stockage. Pour de plus amples informations, veuillez consulter Modification des paramètres de stockage et de performances.

Lorsque vous passez d'un blue/green déploiement à un autre, suivez les meilleures pratiques de transition. Pour de plus amples informations, veuillez consulter Bonnes pratiques de bascule.

É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éplicas en lecture et l’environnement vert pour la réplication des journaux binaires. Si votre moteur de base de données le prend en charge, activez la réplication GTID, parallèle et résistante aux pannes pour garantir la cohérence et la durabilité des données avant de créer votre déploiement. blue/green Pour de plus amples informations, veuillez consulter Utilisation de GTID-based la réplication.

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

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

Planifiez le blue/green passage au cours de la fenêtre de maintenance que vous avez planifiée ou pendant une période de faible activité.

Blue/Green la durée du basculement varie en fonction de votre charge de travail et du nombre de régions secondaires. Lorsque vous lancez une blue/green commutation, le service attend que le délai de réplication atteigne zéro avant de poursuivre. Nous vous recommandons de vérifier le décalage des répliques avant de lancer un basculement.

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

Mettez à jour toutes vos extensions PostgreSQL vers la dernière version avant de créer un blue/green déploiement. Pour de plus amples informations, veuillez consulter Mise à niveau des extensions PostgreSQL dans RDS pour les bases de données RDS pour PostgreSQL.

Long-running les transactions peuvent entraîner un retard de réplication important. Pour réduire le retard de réplica, envisagez les opérations suivantes :

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.

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

Si votre base de données dispose de suffisamment de mémoire disponible, 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 la documentation sur PostgreSQL.

Si vous utilisez l’extension aws_s3, autorisez l’instance de base de données verte à 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.

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.

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 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 Comment effectuer une mise à niveau de version majeure pour RDS pour PostgreSQL.

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