Réplication avec Amazon Aurora MySQL - Amazon Aurora
Réplicas AuroraOptions de réplicationPerformance de réplicationRedémarrage sans interruption (ZDR)Configuration des filtres de réplicationSurveillance de la réplication

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.

Rubriques

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

Important

Les réplicas Aurora pour Aurora MySQL utilisent toujours le niveau d'isolation de transaction par défaut REPEATABLE READ pour les opérations sur les tables InnoDB. Vous pouvez utiliser la commande SET TRANSACTION ISOLATION LEVEL pour modifier uniquement le niveau de transaction de l'instance principale d'un cluster de bases de données Aurora MySQL. 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

Les instructions DDL exécutées sur l'instance principale peuvent interrompre les connexions de base de données sur les réplicas Aurora associés. Si une connexion de réplica Aurora utilise de manière active un objet de base de données, par exemple une table, et que cet objet est modifié sur l'instance principale à l'aide d'une instruction DDL, la connexion du réplica Aurora 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 MySQL

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

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

Redémarrage sans interruption (ZDR) pour Amazon Aurora MySQL

La fonction de redémarrage sans interruption (ZDR) peut préserver une partie ou la totalité des connexions actives aux instances de base de données pendant certains types de redémarrages. Le redémarrage sans interruption s'applique aux redémarrages qu'Aurora exécute automatiquement pour résoudre les conditions d'erreur, par exemple lorsqu'un réplica commence à être trop en retard par rapport à la source.

Important

Le mécanisme de redémarrage sans interruption fonctionne dans la mesure du possible. Les versions d'Aurora MySQL, les classes d'instance, les conditions d'erreur, les opérations SQL compatibles et d'autres facteurs déterminant où s'applique le redémarrage sans interruption peuvent être modifiés à tout moment.

ZDR pour Aurora MySQL 2.x nécessite la version 2.10 ou supérieure. ZDR est disponible dans toutes les versions mineures d'Aurora MySQL 3.x. Dans Aurora MySQL versions 2 et 3, le mécanisme de redémarrage sans interruption est activé par défaut et Aurora n'utilise pas le paramètre aurora_enable_zdr.

Aurora génère des rapports sur les activités de la page Events (Événements) liées au redémarrage sans interruption. Aurora enregistre un événement lorsqu'il tente un redémarrage à l'aide du mécanisme de redémarrage sans interruption. Cet événement explique pourquoi Aurora effectue un redémarrage. Aurora enregistre ensuite un autre événement lorsque le redémarrage est terminé. Cet événement final indique combien de temps le processus a duré et combien de connexions ont été conservées ou supprimées pendant le redémarrage. Vous pouvez consulter le journal des erreurs de la base de données pour en savoir plus sur ce qui s'est passé pendant le redémarrage.

Bien que les connexions restent intactes après une opération de redémarrage sans interruption réussie, certaines variables et fonctions sont réinitialisées. Les types d'informations suivants ne sont pas conservés lors d'un redémarrage causé par un redémarrage sans interruption :

  • Variables globales Aurora restaure les variables de session, mais pas les variables globales après le redémarrage.

  • Variables de statut. En particulier, la valeur de disponibilité signalée par le statut du moteur est réinitialisée.

  • LAST_INSERT_ID.

  • État auto_increment en mémoire pour les tables. L'état d'auto-incrémentation en mémoire est réinitialisé. Pour plus d'informations sur les valeurs d'auto-incrémentation, reportez-vous au manuel de référence MySQL.

  • Les informations de diagnostic des tableaux INFORMATION_SCHEMA et PERFORMANCE_SCHEMA. Ces informations de diagnostic apparaissent également dans la sortie de commandes telles que SHOW PROFILE et SHOW PROFILES.

Le tableau suivant indique les versions, les rôles d'instance et les autres circonstances qui déterminent si Aurora peut utiliser le mécanisme ZDR lors du redémarrage des instances de base de données dans votre cluster.

Aurora MySQL Version Le ZDR s'applique à l'écrivain ? La ZDR s'applique aux lecteurs ? Le ZDR est-il toujours activé ? Remarques

2.x, inférieur à 2.10.0

Non

Non

N/A

Le redémarrage sans interruption n'est pas disponible pour ces versions.

2,1,0—2,11,0

Oui

Oui

Oui

Aurora annule toutes les transactions en cours sur des connexions actives. Votre application doit réessayer les transactions.

Aurora annule toutes les connexions utilisant TLS/SSL, des tables temporaires, des verrous de table ou des verrous utilisateur.

2.11.1 et versions ultérieures

Oui

Oui

Oui

Aurora annule toutes les transactions en cours sur des connexions actives. Votre application doit réessayer les transactions.

Aurora annule toutes les connexions utilisant des tables temporaires, des verrous de table ou des verrous utilisateur.

3,01—3,03

Oui

Oui

Oui

Aurora annule toutes les transactions en cours sur des connexions actives. Votre application doit réessayer les transactions.

Aurora annule toutes les connexions utilisant TLS/SSL, des tables temporaires, des verrous de table ou des verrous utilisateur.

3.04 et versions ultérieures

Oui

Oui

Oui

Aurora annule toutes les transactions en cours sur des connexions actives. Votre application doit réessayer les transactions.

Aurora annule toutes les connexions utilisant des tables temporaires, des verrous de table ou des verrous utilisateur.

Configuration des filtres de réplication avec Aurora MySQL

Vous pouvez utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec un réplica en lecture. Les filtres de réplication peuvent inclure des bases de données et des tables dans la réplication ou les exclure de la réplication.

Voici quelques cas d'utilisation pour les filtres de réplication :

  • Pour réduire la taille d'un réplica en lecture. Avec le filtrage de réplication, vous pouvez exclure les bases de données et les tables qui ne sont pas nécessaires sur le réplica en lecture.

  • Pour exclure des bases de données et des tables des réplicas en lecture, pour des raisons de sécurité.

  • Pour répliquer différentes bases de données et tables pour des cas d'utilisation spécifiques au niveau de différents réplicas en lecture. Par exemple, vous pouvez utiliser des réplicas en lecture spécifiques pour l'analyse ou le partage.

  • Pour un cluster de base de données qui a des réplicas en lecture dans différentes Régions AWS, pour répliquer différentes bases de données ou tables dans des Régions AWS différentes.

  • Pour spécifier quelles bases de données et tables sont répliquées avec un cluster de base de données Aurora MySQL configuré en tant que réplica dans une topologie de réplication entrante. Pour en savoir plus sur cette configuration, consultez Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires).

Définition des paramètres de filtrage de la réplication pour Aurora MySQL

Pour configurer les filtres de réplication, définissez les paramètres suivants :

  • binlog-do-db : répliquer les modifications apportées aux journaux binaires spécifiés. Lorsque vous définissez ce paramètre pour un cluster source de journaux binaires, seuls les journaux binaires spécifiés dans le paramètre sont répliqués.

  • binlog-ignore-db : ne pas répliquer les modifications apportées aux journaux binaires spécifiés. Lorsque le binlog-do-db paramètre est défini pour un cluster source binlog, il n'est pas évalué.

  • replicate-do-db – Répliquer les modifications apportées aux bases de données spécifiées. Lorsque vous définissez ce paramètre pour un cluster de répliques binlog, seules les bases de données spécifiées dans le paramètre sont répliquées.

  • replicate-ignore-db – Ne pas répliquer les modifications apportées aux bases de données spécifiées. Lorsque le replicate-do-db paramètre est défini pour un cluster de répliques binlog, il n'est pas évalué.

  • replicate-do-table – Répliquer les modifications apportées aux tables spécifiées. Lorsque vous définissez ce paramètre pour un réplica en lecture, seules les tables spécifiées dans le paramètre sont répliquées. De même, lorsque le replicate-ignore-db paramètre replicate-do-db ou est défini, veillez à inclure la base de données qui inclut les tables spécifiées dans la réplication avec le cluster de répliques binlog.

  • replicate-ignore-table – Ne pas répliquer les modifications apportées aux tables spécifiées. Lorsque le replicate-do-table paramètre est défini pour un cluster de répliques binlog, il n'est pas évalué.

  • replicate-wild-do-table – Répliquer les tables en fonction des modèles de nom de base de données et nom de table spécifiés. Les caractères génériques % et _ sont pris en charge. Lorsque le replicate-ignore-db paramètre replicate-do-db or est défini, veillez à inclure la base de données qui inclut les tables spécifiées dans la réplication avec le cluster de répliques binlog.

  • replicate-wild-ignore-table – Ne pas répliquer les tables en fonction des modèles de nom de base de données et de nom de table spécifiés. Les caractères génériques % et _ sont pris en charge. Lorsque le replicate-wild-do-table paramètre replicate-do-table or est défini pour un cluster de répliques binlog, ce paramètre n'est pas évalué.

Les paramètres sont évalués dans l'ordre dans lequel ils sont répertoriés. Pour plus d'informations sur le fonctionnement de ces paramètres, consultez la documentation MySQL :

Par défaut, chacun de ces paramètres a une valeur vide. Sur chaque cluster binlog, vous pouvez utiliser ces paramètres pour définir, modifier et supprimer des filtres de réplication. Lorsque vous définissez l'un de ces paramètres, séparez chaque filtre des autres par une virgule.

Vous pouvez utiliser les caractères génériques % et _ dans les paramètres replicate-wild-do-table et replicate-wild-ignore-table. Le caractère générique % correspond à un nombre quelconque de caractères, et le caractère générique _ ne correspond qu'à un seul caractère.

Le format de journalisation binaire de l'instance de base de données source est important pour la réplication, car il détermine l'enregistrement des modifications de données. Le réglage du paramètre binlog_format détermine si la réplication est basée sur les lignes ou les instructions. Pour plus d'informations, consultez Configuration de la journalisation binaire Aurora MySQL.

Note

Toutes les instructions DDL (Data Definition Language) sont répliquées en tant qu'instructions, quel que soit le paramètre binlog_format de l'instance de base de données source.

Limites du filtrage de réplication pour Aurora MySQL

Les limites suivantes s'appliquent au filtrage de réplication pour Aurora MySQL :

  • Les filtres de réplication sont uniquement pris charge pour Aurora MySQL version 3.

  • Chaque paramètre de filtrage de réplication a une limite de 2 000 caractères.

  • Les virgules ne sont pas prises en charge dans les filtres de réplication.

  • Le filtrage de réplication ne prend pas en charge les transactions XA.

    Pour plus d'informations, consultez la section Restrictions on XA Transactions (Restrictions sur les transactions XA) dans la documentation MySQL.

Exemples de filtrage de réplication pour Aurora MySQL

Pour configurer le filtrage de réplication pour un réplica en lecture, modifiez les paramètres de filtrage de réplication dans le groupe de paramètres de cluster de base de données associé au réplica en lecture.

Note

Vous ne pouvez pas modifier un groupe de paramètres de cluster de base de données par défaut. Si le réplica en lecture utilise un groupe de paramètres par défaut, créez un nouveau groupe de paramètres et associez-le au réplica en lecture. Pour plus d'informations sur les groupes de paramètres de cluster de base de données, consultez Utilisation des groupes de paramètres.

Vous pouvez définir des paramètres dans un groupe de paramètres de cluster de base de données à l'aide de la AWS Management Console, de l'interface AWS CLI ou de l'API RDS. Pour plus d'informations sur la définition des paramètres, consultez Modification de paramètres dans un groupe de paramètres de bases de données. Lorsque vous définissez des paramètres dans un groupe de paramètres de cluster de base de données, tous les clusters de bases de données associés au groupe de paramètres utilisent les réglages des paramètres. Si vous définissez les paramètres de filtrage de réplication dans un groupe de paramètres de cluster de base de données, assurez-vous que le groupe de paramètres est associé uniquement aux clusters de réplicas en lecture. Laissez les paramètres de filtrage de réplication vides pour les instances de base de données source.

Les exemples suivants définissent les paramètres à l'aide de la AWS CLI. Ces exemples définissent ApplyMethod sur immediate de sorte que les modifications de paramètre se produisent immédiatement après la fin de la commande de la CLI. Si vous souhaitez qu'une modification en attente soit appliquée après le redémarrage du réplica en lecture, définissez ApplyMethod sur pending-reboot.

Les exemples suivants définissent des filtres de réplication :

Exemple Inclusion de bases de données dans la réplication

L'exemple suivant inclut les bases de données mydb1 et mydb2 dans la réplication.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"

Dans Windows :

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
Exemple Inclusion de tables dans la réplication

L'exemple suivant inclut les tables table1 et table2 dans la base de données mydb1 dans la réplication.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"

Dans Windows :

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
Exemple Inclusion de tables dans la réplication à l'aide de caractères génériques

L'exemple suivant inclut des tables dont les noms commencent par order et return dans la base de données mydb dans la réplication.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"

Dans Windows :

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
Exemple Exclusion de bases de données de la réplication

L'exemple suivant exclut les bases de données mydb5 et mydb6 de la réplication.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"

Dans Windows :

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate"
Exemple Exclusion de tables de la réplication

L'exemple suivant exclut les tables table1 dans la base de données mydb5 et table2 dans la base de données mydb6 de la réplication.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"

Dans Windows :

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
Exemple Exclusion de tables de la réplication à l'aide des caractères génériques

L'exemple suivant exclut de la réplication les tables dont les noms commencent par order et return dans la base de données mydb7.

Pour LinuxmacOS, ou Unix :

aws rds modify-db-cluster-parameter-group \
  --db-cluster-parameter-group-name myparametergroup \
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Dans Windows :

aws rds modify-db-cluster-parameter-group ^
  --db-cluster-parameter-group-name myparametergroup ^
  --parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"

Affichage des filtres de réplication pour un réplica en lecture

Vous pouvez afficher les filtres de réplication pour un réplica en lecture de la manière suivante :

  • Vérifiez les réglages des paramètres de filtrage de réplication dans le groupe de paramètres associé au réplica en lecture.

    Pour obtenir des instructions, consultez Affichage des valeurs de paramètres pour un groupe de paramètres de bases de données.

  • Dans un client MySQL, connectez-vous au réplica en lecture et exécutez l'instruction SHOW REPLICA STATUS.

    Dans la sortie, les champs suivants affichent les filtres de réplication pour le réplica en lecture :

    • Binlog_Do_DB

    • Binlog_Ignore_DB

    • Replicate_Do_DB

    • Replicate_Ignore_DB

    • Replicate_Do_Table

    • Replicate_Ignore_Table

    • Replicate_Wild_Do_Table

    • Replicate_Wild_Ignore_Table

    Pour plus d'informations sur ces champs, consultez la section Vérification du statut de la réplication dans la documentation MySQL.

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.