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 My SQL
Les fonctionnalités de SQL réplication d'Aurora My sont essentielles à la haute disponibilité et aux 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 le fonctionnement d'Aurora My SQL Replication et sur la manière d'affiner les paramètres de réplication pour optimiser la disponibilité et les performances.
Rubriques
- Utilisation de réplicas Aurora
- Options de réplication pour Amazon Aurora My SQL
- Considérations relatives aux performances pour la SQL réplication Amazon Aurora My
- Redémarrage sans interruption de service (ZDR) pour Amazon Aurora My SQL
- Configuration des filtres de réplication avec Aurora My SQL
- Surveillance d'Amazon Aurora My SQL Replication
- Utilisation du transfert d'écriture local dans un cluster Amazon Aurora My SQL DB
- Réplication de clusters Amazon Aurora My SQL DB sur Régions AWS
- Réplication entre Aurora et My SQL ou entre Aurora et un autre cluster de base de données Aurora (réplication de journaux binaires)
- Utilisation de GTID la réplication basée
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é. Jusqu'à 15 répliques Aurora peuvent être distribuées dans les zones de disponibilité qu'un cluster de bases de données couvre au sein d'un Région AWS. Bien que le volume du cluster de base de données soit composé de plusieurs copies des données du cluster de base de données, les données du volume de cluster sont représentées sous la forme d'un volume logique unique pour l'instance principale et pour les répliques Aurora dans le cluster de base 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. Le volume du cluster étant partagé entre toutes les instances de votre cluster Aurora My SQL DB, aucune tâche supplémentaire n'est requise pour répliquer une copie des données pour chaque réplique Aurora. En revanche, les répliques My SQL read doivent rejouer, sur un seul thread, toutes les opérations d'écriture de l'instance de base de données source vers leur magasin de données local. Cette limitation peut affecter la capacité des répliques My SQL read à prendre en charge de gros volumes de trafic de lecture.
Avec Aurora MySQL, lorsqu'une réplique Aurora est supprimée, le point de terminaison de son instance est immédiatement supprimé, et la réplique Aurora est supprimée 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é.
Important
Aurora Replicas for Aurora My utilise SQL toujours le niveau d'isolation des transactions REPEATABLE READ par défaut pour les opérations sur les tables InnoDB. Vous pouvez utiliser la SET TRANSACTION ISOLATION LEVEL commande pour modifier le niveau de transaction uniquement pour l'instance principale d'un cluster Aurora My SQL DB. Cette restriction évite les verrous de niveau utilisateur sur les réplicas Aurora et permet aux réplicas Aurora d'évoluer pour prendre en charge des milliers de connexions utilisateur actives tout en maintenant le retard du réplica à une valeur minimale.
Note
DDLles instructions exécutées sur l'instance principale peuvent interrompre les connexions à la base de données sur les répliques Aurora associées. Si une connexion Aurora Replica utilise activement un objet de base de données, tel qu'une table, et que cet objet est modifié sur l'instance principale à l'aide d'une DDL instruction, la connexion Aurora Replica est interrompue.
Note
La région Chine (Ningxia) ne prend pas en charge les réplicas en lecture entre régions.
Options de réplication pour Amazon Aurora My SQL
Vous pouvez configurer la réplication entre n'importe lesquelles des options suivantes :
-
Deux clusters Aurora My SQL DB différents Régions AWS, en créant une réplique de lecture interrégionale d'un cluster Aurora My SQL DB.
Pour de plus amples informations, veuillez consulter Réplication de clusters Amazon Aurora My SQL DB sur Régions AWS.
-
Deux clusters Aurora My SQL DB dans un même cluster Région AWS, en utilisant la réplication My SQL binary log (binlog).
Pour de plus amples informations, veuillez consulter Réplication entre Aurora et My SQL ou entre Aurora et un autre cluster de base de données Aurora (réplication de journaux binaires).
-
Une instance RDS for My SQL DB comme source et un cluster Aurora My SQL DB, en créant une réplique en lecture Aurora d'une instance RDS for My SQL DB.
Vous pouvez utiliser cette approche pour intégrer les modifications de données existantes et en cours dans Aurora My SQL lors de la migration vers Aurora. Pour de plus amples informations, veuillez consulter Migration de données d'une instance RDS for My SQL DB vers un cluster Amazon Aurora My SQL DB à l'aide d'une réplique de lecture Aurora.
Vous pouvez également utiliser cette approche pour augmenter la scalabilité des requêtes en lecture de vos données. Pour ce faire, interrogez les données à l'aide d'une ou de plusieurs instances de base de données au sein d'un cluster Aurora SQL My en lecture seule. Pour de plus amples informations, veuillez consulter Dimensionnement des lectures pour votre SQL base de données My avec Amazon Aurora.
-
Un cluster Aurora My SQL DB en un Région AWS et jusqu'à cinq clusters Aurora My SQL DB en lecture seule dans différentes régions, en créant une base de données globale Aurora.
Vous pouvez utiliser une base de données Aurora globale pour prendre en charge des applications ayant une présence mondiale. Le cluster Aurora My SQL DB principal possède une instance Writer et jusqu'à 15 répliques Aurora. Les clusters Aurora My SQL DB secondaires en lecture seule peuvent chacun être composés de 16 répliques Aurora. Pour de plus amples informations, veuillez consulter Utilisation de bases de données globales Amazon Aurora.
Note
Le redémarrage de l'instance principale d'un cluster de bases de données Amazon Aurora entraîne automatiquement le redémarrage des réplicas Aurora pour ce cluster de bases de données afin de ré-établir un point d'entrée garantissant la cohérence en lecture/écriture dans le cluster de bases de données.
Considérations relatives aux performances pour la SQL réplication Amazon Aurora My
Les fonctionnalités suivantes vous aident à optimiser les performances de la SQL réplication Aurora My.
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 fonctionnalité implique une certaine CPU surcharge sur le nœud d'écriture pour effectuer la compression. Il est toujours activé dans les SQL versions 2 et 3 d'Aurora My.
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 My SQL version 2, vous pouvez contrôler cette fonctionnalité en modifiant le aurora_enable_repl_bin_log_filtering paramètre. 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, vous pouvez le faire pour correspondre au comportement d'un ancien SQL cluster Aurora My pour lequel cette fonctionnalité n'était pas disponible.
Le filtrage des journaux binaires est toujours activé dans Aurora My SQL version 3.
Surveillance d'Amazon Aurora My SQL Replication
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 Aurora My SQL DB 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 décalage Aurora Replica est également enregistré sur chaque réplique Aurora de votre cluster Aurora My SQL DB dans le information_schema.replica_host_status tableau. Pour plus d'informations sur cette table, consultez information_schema.replica_host_status.
Pour plus d'informations sur la surveillance RDS des instances et CloudWatch des métriques, consultezSurveillance des métriques d'un cluster de bases de données Amazon Aurora.
