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.

Réplication avec Amazon Aurora MySQL

Les fonctions de réplication d'Aurora MySQL sont essentielles pour garantir la haute disponibilité et les performances de votre cluster. Aurora permet de créer ou de redimensionner facilement des clusters avec jusqu'à 15 réplicas Aurora.

Tous les réplicas fonctionnent à partir des mêmes données sous-jacentes. Si certaines instances de base de données passent hors connexion, les autres restent disponibles pour continuer à traiter les requêtes ou pour prendre la relève en tant qu'enregistreur si nécessaire. Aurora répartit automatiquement vos connexions en lecture seule entre plusieurs instances de base de données, ce qui permet à un cluster de prendre en charge des charges de travail exigeantes en requêtes.

Dans les rubriques suivantes, vous trouverez des informations sur la manière dont la réplication Aurora MySQL fonctionne, ainsi que sur le réglage des paramètres de réplication pour garantir une disponibilité et des performances optimales.

Utilisation de réplicas Aurora

Les réplicas Aurora sont les points de terminaison indépendants d'un cluster de bases de données Aurora, utilisés de préférence pour le dimensionnement des opérations de lecture et l'augmentation de la disponibilité. Le nombre de réplicas Aurora pouvant être distribués entre les zones de disponibilité que couvre un cluster de bases de données au sein d'une Région AWS est limité à 15. Même si le volume du cluster de bases de données est composé de plusieurs copies des données pour le cluster de bases de données, les données du volume de cluster sont représentées comme un seul volume logique à l'instance principale et aux réplicas Aurora du cluster de bases de données. Pour plus d'informations sur les réplicas Aurora, consultez Réplicas Aurora.

Les réplicas Aurora fonctionnement parfaitement pour le dimensionnement en lecture, car ils sont intégralement dédiés aux opérations de lecture de votre volume de cluster. Les opérations d'écriture sont gérées par l'instance principale. Comme le volume de cluster est partagé entre toutes les instances de votre cluster de bases de données Aurora MySQL, aucun travail supplémentaire n'est nécessaire pour répliquer une copie des données pour chaque réplica Aurora. En revanche, les réplicas en lecture MySQL doivent relire, sur un seul thread, toutes les opérations d'écriture depuis l'instance de base de données source vers leur magasin de données local. Cette limitation peut affecter la capacité des réplicas en lecture MySQL à prendre en charge d'importants volumes de trafic en lecture.

Avec Aurora MySQL, quand un réplica Aurora est supprimé, le point de terminaison de son instance est supprimé immédiatement et le réplica Aurora est supprimé du point de terminaison du lecteur. S'il y a des instructions qui s'exécutent sur le réplica Aurora en cours de suppression, une période de grâce de trois minutes est accordée. Les instructions existantes peuvent se terminer élégamment pendant la période de grâce. Lorsque la période de grâce se termine, le réplica Aurora est arrêté et supprimé.

Options de réplication pour Amazon Aurora MySQL

Vous pouvez configurer la réplication entre n'importe lesquelles des options suivantes :

Considérations sur les performances pour la réplication Amazon Aurora MySQL

Les fonctions suivantes vous permettent d'affiner les performances d'une réplication Aurora MySQL.

La fonction de compression des journaux de réplica réduit automatiquement la bande passante réseau pour les messages de réplication. Étant donné que chaque message est transmis à tous les réplicas Aurora, les avantages sont supérieurs pour les clusters plus volumineux. Cette fonction implique une certaine surcharge de l'UC sur le nœud d'enregistreur pour effectuer la compression. Elle est toujours activée dans Aurora MySQL version 2 et 3.

La fonction de filtrage des journaux binaires réduit automatiquement la bande passante réseau pour les messages de réplication. Étant donné que les réplicas Aurora n'utilisent pas les informations de journal binaire qui sont incluses dans les messages de réplication, ces données sont omises dans les messages envoyés à ces nœuds.

Dans Aurora MySQL version 2, vous pouvez contrôler cette fonctionnalité en modifiant le paramètre aurora_enable_repl_bin_log_filtering. Ce paramètre est activé par défaut. Étant donné que cette optimisation est conçue pour être transparente, vous pouvez désactiver ce paramètre uniquement pendant le diagnostic ou le dépannage des problèmes liés à la réplication, par exemple pour correspondre au comportement d'un ancien cluster Aurora MySQL où cette fonction n'était pas disponible.

Le filtrage des journaux binaires est toujours activé dans Aurora MySQL version 3.

Surveillance de la réplication Amazon Aurora MySQL

Le dimensionnement en lecture et la haute disponibilité dépendent d'un temps de retard minimal. Vous pouvez surveiller le retard d'une réplique Aurora par rapport à l'instance principale de votre cluster de bases de données Aurora MySQL en surveillant la CloudWatch AuroraReplicaLag métrique Amazon. La métrique AuroraReplicaLag est enregistrée dans chaque réplica Aurora.

L'instance de base de données principale enregistre également les CloudWatch métriques AuroraReplicaLagMaximum et AuroraReplicaLagMinimum Amazon. La métrique AuroraReplicaLagMaximum enregistre le décalage maximal entre l'instance de base de données principale et chaque réplica Aurora dans le cluster de bases de données. La métrique AuroraReplicaLagMinimum enregistre le décalage minimal entre l'instance de base de données principale et chaque réplica Aurora dans le cluster de bases de données.

Si vous avez besoin de la valeur la plus récente pour le décalage d'Aurora Replica, vous pouvez consulter la AuroraReplicaLag métrique sur Amazon CloudWatch. Le retard de réplica Aurora est également enregistré sur chaque réplica Aurora de votre cluster de bases de données Aurora MySQL dans la table information_schema.replica_host_status. Pour plus d'informations sur cette table, consultez information_schema.replica_host_status.

Pour plus d'informations sur la surveillance des instances et des CloudWatch métriques RDS, consultezSurveillance des métriques d'un cluster de bases de données Amazon Aurora.