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. **Topics** + [Utilisation de réplicas Aurora](#AuroraMySQL.Replication.Replicas) + [Options de réplication pour Amazon Aurora MySQL](#AuroraMySQL.Replication.Options) + [Considérations sur les performances pour la réplication Amazon Aurora MySQL](#AuroraMySQL.Replication.Performance) + [Configuration des filtres de réplication avec Aurora MySQL](AuroraMySQL.Replication.Filters.md) + [Surveillance de la réplication Amazon Aurora MySQL](#AuroraMySQL.Replication.Monitoring) + [Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS](AuroraMySQL.Replication.CrossRegion.md) + [Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires)](AuroraMySQL.Replication.MySQL.md) + [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md) ## 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](Aurora.Replication.md#Aurora.Replication.Replicas). 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 : + Deux clusters de bases de données Aurora MySQL dans des Régions AWS différentes, en créant un réplica en lecture entre régions d'un cluster de bases de données Aurora MySQL. Pour de plus amples informations, consultez [Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS](AuroraMySQL.Replication.CrossRegion.md). + Deux clusters de bases de données Aurora MySQL dans la même Région AWS, en utilisant la réplication du journal binaire (binlog) MySQL. Pour de plus amples informations, 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)](AuroraMySQL.Replication.MySQL.md). + Une instance source de bases de données RDS for MySQL et un cluster de bases de données Aurora MySQL, en créant un réplica en lecture Aurora d'une instance de bases de données RDS for MySQL. Vous pouvez utiliser cette approche pour intégrer les modifications de données existantes et en cours à Aurora MySQL lors de la migration vers Aurora. Pour de plus amples informations, consultez [Migration des données d’une instance de base de données RDS for MySQL vers un cluster de bases de données Amazon Aurora MySQL à l’aide d’un réplica en lecture Aurora](AuroraMySQL.Migrating.RDSMySQL.Replica.md). 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 dans un cluster Aurora MySQL en lecture seule. Pour de plus amples informations, consultez [Mise à l’échelle des lectures pour votre base de données MySQL avec Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md). + Un cluster de bases de données Aurora MySQL dans une Région AWS et jusqu'à cinq clusters de bases de données Aurora MySQL en lecture seule Aurora dans différentes régions, en créant une base de données Aurora globale. Vous pouvez utiliser une base de données Aurora globale pour prendre en charge des applications ayant une présence mondiale. Le cluster de bases de données Aurora MySQL principal possède une instance de scripteur et jusqu'à 15 réplicas Aurora. Les clusters de bases de données Aurora MySQL secondaires en lecture seule peuvent être composés de 16 réplicas Aurora maximum. Pour plus d'informations, consultez [Utilisation d’Amazon Aurora Global Database](aurora-global-database.md). **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. # 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 bases 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 bases 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)](AuroraMySQL.Replication.MySQL.md). **Topics** + [Définition des paramètres de filtrage de la réplication pour Aurora MySQL](#AuroraMySQL.Replication.Filters.Configuring) + [Limites du filtrage de réplication pour Aurora MySQL](#AuroraMySQL.Replication.Filters.Limitations) + [Exemples de filtrage de réplication pour Aurora MySQL](#AuroraMySQL.Replication.Filters.Examples) + [Affichage des filtres de réplication pour un réplica en lecture](#AuroraMySQL.Replication.Filters.Viewing) ## Définition des paramètres de filtrage de la réplication pour Aurora MySQL Pour configurer des 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 paramètre `binlog-do-db` est défini pour un cluster source de journaux binaires, ce paramètre 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éplica de journaux binaires, 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 paramètre `replicate-do-db` est défini pour un cluster de réplica de journaux binaires, ce paramètre 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. En outre, lorsque le paramètre `replicate-do-db` ou `replicate-ignore-db` est défini, assurez-vous d’inclure la base de données qui comprend les tables spécifiées dans la réplication avec le cluster de réplica des journaux binaires. + `replicate-ignore-table` – Ne pas répliquer les modifications apportées aux tables spécifiées. Lorsque le paramètre `replicate-do-table` est défini pour un cluster de réplica de journaux binaires, ce paramètre 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 paramètre `replicate-do-db` ou `replicate-ignore-db` est défini, assurez-vous d’inclure la base de données qui comprend les tables spécifiées dans la réplication avec le cluster de réplica des journaux binaires. + `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 paramètre `replicate-do-table` ou `replicate-wild-do-table` est défini pour un cluster de réplica de journaux binaires, 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 : + Pour plus d’informations générales, voir [ Options et variables du serveur de réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html). + Pour plus d’informations sur la façon dont les paramètres de filtrage de réplication de base de données sont évalués, voir [ Évaluation des options de réplication au niveau de la base de données et des options de la journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-db-options.html). + Pour plus d’informations sur l’évaluation des paramètres de filtrage de réplication de table, reportez-vous à la section [ Évaluation des options de réplication au niveau de la table](https://dev.mysql.com/doc/refman/8.0/en/replication-rules-table-options.html). Par défaut, chacun de ces paramètres a une valeur vide. Sur chaque cluster de journaux binaires, 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 d'Aurora MySQL les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md). **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 [Restrictions on XA Transactions (Restrictions sur les transactions XA)](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) 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 bases de données associé au réplica en lecture. **Note** Vous ne pouvez pas modifier un groupe de paramètres de cluster de bases 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 bases de données, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). Vous pouvez définir des paramètres dans un groupe de paramètres de cluster de bases 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 base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Modifying.md). Lorsque vous définissez des paramètres dans un groupe de paramètres de cluster de bases 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 bases 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 : + [Including databases in replication](#rep-filter-in-dbs-ams) + [Including tables in replication](#rep-filter-in-tables-ams) + [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-ams) + [Excluding databases from replication](#rep-filter-ex-dbs-ams) + [Excluding tables from replication](#rep-filter-ex-tables-ams) + [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-ams) **Example 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 Linux, macOS 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" ``` Pour Windows : ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate" ``` **Example 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 Linux, macOS 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" ``` Pour 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" ``` **Example 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 Linux, macOS 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" ``` Pour 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" ``` **Example 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 Linux, macOS 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" ``` Pour Windows : ``` aws rds modify-db-cluster-parameter-group ^ --db-cluster-parameter-group-name myparametergroup ^ --parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6,ApplyMethod=immediate" ``` **Example 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 Linux, macOS 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" ``` Pour 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" ``` **Example 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 Linux, macOS 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" ``` Pour 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 base de données dans Amazon Aurora](USER_WorkingWithParamGroups.Viewing.md). + 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 [Vérification du statut de la réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-administration-status.html) 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 jusqu'à quel point un réplica Aurora est en retard par rapport à l'instance principale de votre cluster de bases de données Aurora MySQL en surveillant la métrique Amazon CloudWatch `AuroraReplicaLag`. La métrique `AuroraReplicaLag` est enregistrée dans chaque réplica Aurora. L'instance de base de données principale enregistre également les métriques Amazon CloudWatch `AuroraReplicaLagMaximum` et `AuroraReplicaLagMinimum`. 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 actuelle du retard de réplica Aurora, vous pouvez consulter la métrique `AuroraReplicaLag` dans 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\$1schema.replica\$1host\$1status](AuroraMySQL.Reference.ISTables.md#AuroraMySQL.Reference.ISTables.replica_host_status). Pour plus d'informations sur la surveillance des instances RDS et des métriques CloudWatch, consultez [Surveillance des métriques d’un cluster de bases de données Amazon Aurora](MonitoringAurora.md). # Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS Vous pouvez créer un cluster de bases de données Amazon Aurora MySQL en tant que réplica en lecture dans une Région AWS autre que celle du cluster de bases de données source. Cette approche vous permet d’améliorer vos capacités de reprise après sinistre, de faire évoluer les opérations de lecture dans une Région AWS qui est plus proche de vos utilisateurs et de faciliter la migration d’une Région AWS à une autre. Vous pouvez créer des réplicas en lecture pour les clusters de bases de données chiffrés et non chiffrés. Le réplica en lecture doit être chiffré si le cluster de bases de données source est chiffré. Pour chaque cluster de bases de données source, vous pouvez avoir jusqu’à cinq clusters de bases de données entre régions qui sont des réplicas en lecture. **Note** Comme alternative aux réplicas en lecture entre régions, vous pouvez mettre à l’échelle les opérations de lecture avec un temps de latence minimal à l’aide d’une base de données Aurora globale. Une base de données Aurora globale a un cluster de bases de données Aurora principal dans une Région AWS, et jusqu’à 10 clusters de bases de données secondaires en lecture seule dans d’autres régions. Chaque cluster de bases de données secondaire peut inclure jusqu’à 16 réplicas Aurora (plutôt que 15). La réplication du cluster de bases de données primaire vers tous les clusters secondaires est gérée par la couche de stockage Aurora plutôt que par le moteur de base de données. Ainsi, le temps de latence de réplication des modifications est minime (généralement inférieur à 1 seconde). Exclure le moteur de base de données du processus de réplication permet de le dédier au traitement des charges de travail. En outre, vous n’avez pas besoin de configurer ou de gérer la réplication binlog (journalisation binaire) d’Aurora MySQL. Pour en savoir plus, consultez [Utilisation d’Amazon Aurora Global Database](aurora-global-database.md). Lorsque vous créez un réplica en lecture de cluster de bases de données Aurora MySQL dans une autre Région AWS, vous devez être conscient des points suivants : + Votre cluster de bases de données source et votre cluster de bases de données de réplica en lecture entre régions peuvent avoir jusqu’à 15 réplicas Aurora, avec l’instance principale du cluster de bases de données. En utilisant cette fonctionnalité, vous pouvez mettre à l’échelle les opérations de lecture pour votre Région AWS source et votre Région AWS cible de réplication. + Dans un scénario entre régions, le retard entre le cluster de bases de données source et le réplica en lecture est plus important du fait que les canaux de réseau entre les Régions AWS sont plus longs. + Les données transférées pour la réplication entre régions génèrent des frais de transfert de données Amazon RDS. Les actions de réplication entre régions suivantes génèrent des frais pour les données transférées hors de la Région AWS source : + Lorsque vous créez le réplica en lecture, Amazon RDS prend un instantané du cluster source et transfère cet instantané vers la Région AWS où se trouve le réplica en lecture. + Pour chaque modification des données effectuée dans les bases de données source, Amazon RDS transfère les données de la région source vers la Région AWS où se trouve le réplica en lecture. Pour plus d’informations sur la tarification du transfert de données Amazon RDS, consultez [Tarification Amazon Aurora](https://aws.amazon.com/rds/aurora/pricing/). + Vous pouvez exécuter plusieurs actions de création ou de suppression simultanées pour les réplicas en lecture qui référencent le même cluster de bases de données source. Vous devez toutefois rester dans la limite de cinq réplicas en lecture pour chaque cluster de bases de données source. + Pour que la réplication fonctionne de façon efficace, chaque réplica en lecture doit avoir la même quantité de ressources de calcul et de stockage que le cluster de bases de données source. Si vous mettez à l’échelle le cluster de bases de données source, vous devez également le faire pour les réplicas en lecture. **Topics** + [Avant de commencer](#AuroraMySQL.Replication.CrossRegion.Prerequisites) + [Création d’un cluster de bases de données de réplica en lecture entre régions pour Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Creating.md) + [Promotion d’un réplica en lecture en cluster de bases de données pour Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Promote.md) + [Dépannage des réplicas entre régions pour Amazon Aurora MySQL](AuroraMySQL.Replication.CrossRegion.Troubleshooting.md) ## Avant de commencer Pour pouvoir créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions, vous devez commencer par activer la journalisation binaire sur votre cluster de bases de données Aurora MySQL source. La réplication entre régions pour Aurora MySQL utilise la réplication binaire MySQL pour relire les modifications apportées au cluster de bases de données du réplica en lecture entre régions. Pour activer la journalisation binaire sur un cluster de bases de données Aurora MySQL, mettez à jour le paramètre `binlog_format` de votre cluster de bases de données source. Le paramètre `binlog_format` est un paramètre de niveau cluster qui figure dans le groupe de paramètres de cluster par défaut. Si votre cluster de bases de données utilise le groupe de paramètres de cluster de bases de données par défaut, créez un nouveau groupe de paramètres de cluster de bases de données pour modifier les paramètres `binlog_format`. Nous vous recommandons de définir le `binlog_format` sur `MIXED`. Cependant, vous pouvez également définir `binlog_format` sur `ROW` ou `STATEMENT` si vous avez besoin d’un format binlog spécifique. Redémarrez votre cluster de bases de données Aurora pour que les modifications prennent effet. Pour plus d’informations sur l’utilisation de la journalisation binaire Aurora, 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)](AuroraMySQL.Replication.MySQL.md). Pour plus d’informations sur la modification des paramètres de configuration de Aurora MySQL, consultez [Paramètres de cluster de bases de données et d’instance de base de données Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) et [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). # Création d’un cluster de bases de données de réplica en lecture entre régions pour Aurora MySQL Vous pouvez créer un cluster de bases de données Aurora en tant que réplica en lecture entre régions à l’aide de l’AWS Management Console, de l’AWS Command Line Interface (AWS CLI) ou de l’API Amazon RDS. Vous pouvez créer des réplicas en lecture entre régions à partir des clusters de bases de données chiffrés et non chiffrés. Lorsque vous créez un réplica en lecture entre régions pour Aurora MySQL à l’aide de l’AWS Management Console, Amazon RDS crée un cluster de bases de données dans la Région AWS cible, puis crée automatiquement une instance de base de données qui est l’instance principale de ce cluster de bases de données. Lorsque vous créez un réplica en lecture entre régions à l’aide de la AWS CLI ou de l’API RDS, vous devez commencer par créer le cluster de bases de données dans la Région AWS cible, puis attendre qu’il devienne actif. Une fois qu’il est actif, vous pouvez alors créer une instance de base de données qui est l’instance principale de ce cluster de bases de données. La réplication commence lorsque l’instance principale du cluster de bases de données de réplica en lecture devient disponible. Procédez comme suit pour créer un réplica en lecture entre régions à partir d’un cluster de bases de données Aurora MySQL. Ces procédures permettent de créer des réplicas en lecture à partir de clusters de bases de données chiffrés ou non chiffrés. ## Console **Pour créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions avec l’AWS Management Console** 1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Dans le coin supérieur droit d’AWS Management Console, sélectionnez la Région AWS qui héberge votre cluster de bases de données source. 1. Dans la panneau de navigation, choisissez **Bases de données**. 1. Sélectionnez le cluster de bases de données pour lequel vous souhaitez créer un réplica en lecture entre régions. 1. Pour **Actions**, choisissez **Create cross-Region read replica** (Créer un réplica en lecture entre régions). 1. Sur la page **Créer un réplica en lecture entre régions**, choisissez les paramètres d’option de votre cluster de bases de données de réplica en lecture entre régions, comme décrit dans le tableau suivant. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.CrossRegion.Creating.html) 1. Choisissez **Créer** pour créer votre réplica en lecture entre régions pour Aurora. ## AWS CLI **Pour créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions avec la CLI** 1. Appelez la commande AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) dans la Région AWS où vous voulez créer le cluster de bases de données de réplica en lecture. Incluez l’option `--replication-source-identifier` et indiquez l’Amazon Resource Name (ARN) du cluster de bases de données source pour lequel vous créez un réplica en lecture. Pour une réplication entre régions où le cluster de bases de données identifié par `--replication-source-identifier` est chiffré, spécifiez les options `--kms-key-id` et `--storage-encrypted`. **Note** Vous pouvez configurer la réplication entre régions à partir d’un cluster de bases de données non chiffré vers un réplica en lecture chiffré en spécifiant `--storage-encrypted` et en fournissant une valeur pour l’option `--kms-key-id`. Vous ne pouvez pas spécifier les paramètres `--master-username` et `--master-user-password`. Ces valeurs sont extraites du cluster de bases de données source. L’exemple de code suivant crée un réplica en lecture dans la région us-east-1 à partir d’un instantané du cluster de bases de données non chiffré dans la région us-west-2. La commande est appelée dans la région us-east-1. Cet exemple spécifie l’option `--manage-master-user-password` permettant de générer le mot de passe de l’utilisateur principal et de le gérer dans Secrets Manager. Pour plus d’informations, consultez [Gestion des mots de passe avec Amazon Aurora et AWS Secrets Manager](rds-secrets-manager.md). Vous pouvez également utiliser l’option `--master-password` pour spécifier et gérer vous-même le mot de passe. Pour Linux, macOS ou Unix : ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` Pour Windows : ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ``` L’exemple de code suivant crée un réplica en lecture dans la région us-east-1 à partir d’un instantané du cluster de bases de données chiffré dans la région us-west-2. La commande est appelée dans la région us-east-1. Pour Linux, macOS ou Unix : ``` aws rds create-db-cluster \ --db-cluster-identifier sample-replica-cluster \ --engine aurora-mysql \ --engine-version 8.0.mysql_aurora.3.08.0 \ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster \ --kms-key-id my-us-east-1-key \ --storage-encrypted ``` Pour Windows : ``` aws rds create-db-cluster ^ --db-cluster-identifier sample-replica-cluster ^ --engine aurora-mysql ^ --engine-version 8.0.mysql_aurora.3.08.0 ^ --replication-source-identifier arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster ^ --kms-key-id my-us-east-1-key ^ --storage-encrypted ``` L’option `--source-region` est obligatoire pour la réplication entre les régions AWS GovCloud (US-East) et AWS GovCloud (US-West), où le cluster de bases de données identifié par `--replication-source-identifier` est chiffré. Pour `--source-region`, spécifiez la Région AWS du cluster de bases de données source. Si `--source-region` n’est pas spécifié, spécifiez une valeur `--pre-signed-url`. Une *URL présignée* est une URL qui contient une demande signée via Signature Version 4 pour la commande `create-db-cluster` qui est appelée dans la Région AWS source. Pour en savoir plus sur l’option `pre-signed-url`, consultez [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) dans le manuel *AWS CLI Command Reference*. 1. Vérifiez que le cluster de bases de données est disponible pour être utilisé à l’aide de la commande AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html), comme indiqué dans l’exemple suivant. ``` aws rds describe-db-clusters --db-cluster-identifier sample-replica-cluster ``` Lorsque les résultats **`describe-db-clusters`** affichent le statut `available`, créez l’instance principale pour le cluster de bases de données afin que la réplication commence. Pour ce faire, utilisez la commande AWS CLI [create-db-instance](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-instance.html), comme illustré dans l’exemple suivant. Pour Linux, macOS ou Unix : ``` aws rds create-db-instance \ --db-cluster-identifier sample-replica-cluster \ --db-instance-class db.r5.large \ --db-instance-identifier sample-replica-instance \ --engine aurora-mysql ``` Pour Windows : ``` aws rds create-db-instance ^ --db-cluster-identifier sample-replica-cluster ^ --db-instance-class db.r5.large ^ --db-instance-identifier sample-replica-instance ^ --engine aurora-mysql ``` Lorsque l’instance de base de données est créée et disponible, la réplication commence. Vous pouvez déterminer si l’instance de base de données est disponible en appelant la commande AWS CLI [describe-db-instances](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html). ## API RDS **Pour créer un cluster de bases de données Aurora MySQL en tant que réplica en lecture entre régions avec l’API** 1. Appelez l’opération [CreateDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBCluster.html) de l’API RDS dans la Région AWS où vous voulez créer le cluster de bases de données de réplica en lecture. Incluez le paramètre `ReplicationSourceIdentifier` et indiquez l’Amazon Resource Name (ARN) du cluster de bases de données source pour lequel vous créez un réplica en lecture. Pour une réplication entre régions où le cluster de bases de données identifié par `ReplicationSourceIdentifier` est chiffré, spécifiez le paramètre `KmsKeyId` et définissez le paramètre `StorageEncrypted` sur `true`. **Note** Vous pouvez configurer la réplication entre régions à partir d’un cluster de bases de données non chiffré vers un réplica en lecture chiffré en définissant `StorageEncrypted` sur **true** et en fournissant une valeur pour l’option `KmsKeyId`. Dans ce cas, il n’est pas nécessaire de spécifier `PreSignedUrl`. Vous n’avez pas besoin d’inclure les paramètres `MasterUsername` et `MasterUserPassword`, parce que ces valeurs sont extraites du cluster de bases de données source. L’exemple de code suivant crée un réplica en lecture dans la région us-east-1 à partir d’un instantané du cluster de bases de données non chiffré dans la région us-west-2. L’action est appelée dans la région us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` L’exemple de code suivant crée un réplica en lecture dans la région us-east-1 à partir d’un instantané du cluster de bases de données chiffré dans la région us-west-2. L’action est appelée dans la région us-east-1. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBCluster &KmsKeyId=my-us-east-1-key &StorageEncrypted=true &PreSignedUrl=https%253A%252F%252Frds.us-west-2.amazonaws.com%252F %253FAction%253DCreateDBCluster %2526DestinationRegion%253Dus-east-1 %2526KmsKeyId%253Dmy-us-east-1-key %2526ReplicationSourceIdentifier%253Darn%25253Aaws%25253Ards%25253Aus-west-2%25253A123456789012%25253Acluster%25253Asample-master-cluster %2526SignatureMethod%253DHmacSHA256 %2526SignatureVersion%253D4 %2526Version%253D2014-10-31 %2526X-Amz-Algorithm%253DAWS4-HMAC-SHA256 %2526X-Amz-Credential%253DAKIADQKE4SARGYLE%252F20161117%252Fus-west-2%252Frds%252Faws4_request %2526X-Amz-Date%253D20161117T215409Z %2526X-Amz-Expires%253D3600 %2526X-Amz-SignedHeaders%253Dcontent-type%253Bhost%253Buser-agent%253Bx-amz-content-sha256%253Bx-amz-date %2526X-Amz-Signature%253D255a0f17b4e717d3b67fad163c3ec26573b882c03a65523522cf890a67fca613 &ReplicationSourceIdentifier=arn:aws:rds:us-west-2:123456789012:cluster:sample-master-cluster &DBClusterIdentifier=sample-replica-cluster &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T001547Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=a04c831a0b54b5e4cd236a90dcb9f5fab7185eb3b72b5ebe9a70a4e95790c8b7 ``` Pour la réplication entre les régions AWS GovCloud (US-East) et AWS GovCloud (US-West), où le cluster de bases de données identifié par `ReplicationSourceIdentifier` est chiffré, spécifiez également le paramètre `PreSignedUrl`. L’URL présignée doit être une demande valide pour l’opération d’API `CreateDBCluster`, laquelle peut être effectuée dans la Région AWS source qui contient le cluster de bases de données chiffré à répliquer. L’identifiant de clé KMS qui permet de chiffrer le réplica en lecture, qui doit être une clé KMS valide pour la Région AWS de destination. Pour générer automatiquement plutôt que manuellement une URL présignée, utilisez plutôt la commande AWS CLI [create-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/create-db-cluster.html) avec l’option `--source-region`. 1. Vérifiez que le cluster de bases de données est disponible pour être utilisé avec l’opération [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) de l’API RDS, comme indiqué dans l’exemple suivant. ``` https://rds.us-east-1.amazonaws.com/ ?Action=DescribeDBClusters &DBClusterIdentifier=sample-replica-cluster &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T002223Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=84c2e4f8fba7c577ac5d820711e34c6e45ffcd35be8a6b7c50f329a74f35f426 ``` Lorsque les résultats `DescribeDBClusters` affichent le statut `available`, créez l’instance principale pour le cluster de bases de données afin que la réplication commence. Pour ce faire, utilisez l’action [CreateDBInstance](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_CreateDBInstance.html) de l’API RDS, comme illustré dans l’exemple suivant. ``` https://rds.us-east-1.amazonaws.com/ ?Action=CreateDBInstance &DBClusterIdentifier=sample-replica-cluster &DBInstanceClass=db.r5.large &DBInstanceIdentifier=sample-replica-instance &Engine=aurora-mysql &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Version=2014-10-31 &X-Amz-Algorithm=AWS4-HMAC-SHA256 &X-Amz-Credential=AKIADQKE4SARGYLE/20161117/us-east-1/rds/aws4_request &X-Amz-Date=20160201T003808Z &X-Amz-SignedHeaders=content-type;host;user-agent;x-amz-content-sha256;x-amz-date &X-Amz-Signature=125fe575959f5bbcebd53f2365f907179757a08b5d7a16a378dfa59387f58cdb ``` Lorsque l’instance de base de données est créée et disponible, la réplication commence. Vous pouvez déterminer si l’instance de base de données est disponible en appelant la commande AWS CLI [DescribeDBInstances](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBInstances.html). ## Affichage des réplicas entre régions Amazon Aurora MySQL Vous pouvez afficher les relations de réplication entre régions de vos clusters de bases de données Amazon Aurora MySQL en appelant la commande AWS CLI [describe-db-clusters](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-clusters.html) ou l’opération [DescribeDBClusters](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_DescribeDBClusters.html) de l’API RDS. Dans la réponse, reportez-vous au champ `ReadReplicaIdentifiers` pour obtenir les identifiants de cluster de bases de données de tous les clusters de bases de données de réplica en lecture entre régions. Reportez-vous à l’élément `ReplicationSourceIdentifier` pour obtenir l’ARN du cluster de bases de données source qui est la source de réplication. # Promotion d’un réplica en lecture en cluster de bases de données pour Aurora MySQL Vous pouvez promouvoir un réplica en lecture Aurora MySQL en cluster de bases de données autonome. Lorsque vous promouvez un réplica en lecture Aurora MySQL, les instances de base de données sont redémarrées avant de devenir disponibles. En règle générale, vous effectuez la promotion d’un réplica en lecture Aurora MySQL en cluster de bases de données autonome comme plan de récupération des données en cas de défaillance du cluster de bases de données source. Pour cela, commencez par créer un réplica en lecture, puis surveillez le cluster de bases de données source pour détecter les défaillances. En cas de panne, procédez comme suit : 1. Promouvez le réplica en lecture. 1. Dirigez le trafic de base de données vers le cluster de bases de données promu. 1. Créez un réplica en lecture de remplacement en utilisant le cluster de bases de données promu comme source. Lorsque vous effectuez la promotion d’un réplica en lecture, celui-ci devient un cluster de bases de données Aurora autonome. Le processus de promotion peut prendre plusieurs minutes ou plus longtemps, selon la taille du réplica en lecture. Une fois le réplica en lecture promu en nouveau cluster de bases de données, il est similaire à tout autre cluster de bases de données. Par exemple, vous pouvez créer des réplicas en lecture à partir de celui-ci et effectuer des opérations de restauration à un moment donné. Vous pouvez également créer des réplicas Aurora pour le cluster de bases de données. Étant donné que le cluster de bases de données promu n’est plus un réplica en lecture, vous ne pouvez pas l’utiliser comme cible de réplication. Les étapes suivantes décrivent le processus général de promotion d’un réplica en lecture en cluster de bases de données : 1. Arrêtez l’écriture de toute transaction sur le cluster de bases de données source du réplica en lecture, puis attendez que toutes les mises à jour soient terminées sur le réplica en lecture. Les mises à jour de la base de données ont lieu sur les réplicas en lecture après avoir eu lieu sur le cluster de bases de données source, et cette latence de réplication peut varier de façon significative. Utilisez la métrique `ReplicaLag` pour déterminer à quel moment toutes les mises à jour ont été effectuées sur le réplica en lecture. La métrique `ReplicaLag` enregistre la durée pendant laquelle une instance de base de données de réplica en lecture retarde l’instance de base de données source. Lorsque la métrique `ReplicaLag` atteint `0`, le réplica en lecture a rattrapé l’instance de base de données source. 1. Promouvez le réplica en lecture à l’aide de l’option **Promote** (Promouvoir) sur la console Amazon RDS, de la commande AWS CLI [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html) ou de l’opération [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html) de l’API Amazon RDS. Vous choisissez une instance de base de données Aurora MySQL pour promouvoir le réplica en lecture. Une fois le réplica en lecture promu, le cluster de bases de données Aurora MySQL est promu en cluster de bases de données autonome. L’instance de base de données ayant la priorité de basculement la plus élevée est promue en instance de base de données pour le cluster de bases de données. Les autres instances de base de données deviennent des réplicas Aurora. **Note** Le processus de promotion dure quelques minutes. Lorsque vous promouvez un réplica en lecture, la réplication est arrêtée et les instances de base de données sont redémarrées. Une fois le redémarrage terminé, le réplica en lecture est disponible en tant que nouveau cluster de bases de données. ## Console **Pour promouvoir un réplica en lecture Aurora MySQL en cluster de bases de données** 1. Connectez-vous à la AWS Management Console et ouvrez la console Amazon RDS à l’adresse [https://console.aws.amazon.com/rds/](https://console.aws.amazon.com/rds/). 1. Dans la console, choisissez **Instances**. Le panneau **Instance** s’affiche. 1. Dans le panneau **Instances**, choisissez le réplica en lecture que vous souhaitez promouvoir. Les réplicas en lecture apparaissent comme instances de base de données Aurora MySQL. 1. Sous **Actions**, choisissez **Promouvoir le réplica en lecture**. 1. Dans la page de confirmation, sélectionnez **Promote read replica (Promouvoir le réplica en lecture)**. ## AWS CLI Pour promouvoir un réplica en lecture en cluster de bases de données, utilisez la commande AWS CLI [promote-read-replica-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/promote-read-replica-db-cluster.html). **Example** Pour Linux, macOS ou Unix : ``` aws rds promote-read-replica-db-cluster \ --db-cluster-identifier mydbcluster ``` Pour Windows : ``` aws rds promote-read-replica-db-cluster ^ --db-cluster-identifier mydbcluster ``` ## API RDS Pour promouvoir un réplica en lecture en cluster de bases de données, appelez [PromoteReadReplicaDBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_PromoteReadReplicaDBCluster.html). # Dépannage des réplicas entre régions pour Amazon Aurora MySQL La liste ci-dessous répertorie les messages d’erreur courants que vous pouvez rencontrer lors de la création d’un réplica en lecture entre régions Amazon Aurora et indique comment les résoudre. ## Source cluster [DB cluster ARN] doesn’t have binlogs enabled Pour résoudre ce problème, activez la journalisation binaire sur le cluster de bases de données source. Pour plus d’informations, consultez [Avant de commencer](AuroraMySQL.Replication.CrossRegion.md#AuroraMySQL.Replication.CrossRegion.Prerequisites). ## Source cluster [DB cluster ARN] doesn’t have cluster parameter group in sync on writer Vous recevez cette erreur si vous avez mis à jour le paramètre du cluster de bases de données `binlog_format` sans redémarrer l’instance principale du cluster de bases de données. Redémarrez l’instance principale (c’est-à-dire, l’auteur) du cluster de bases de données, puis réessayez. ## Source cluster [DB cluster ARN] already has a read replica in this region Vous pouvez avoir jusqu’à cinq clusters de bases de données inter-régions constituant des réplicas en lecture pour chaque cluster de bases de données source dans n’importe quelle Région AWS. Si vous disposez déjà du nombre maximal de réplicas en lecture pour un cluster de bases de données dans une Région AWS particulière, vous devez supprimer un cluster existant avant de pouvoir créer un cluster de bases de données inter-régions dans cette région. ## DB cluster [DB cluster ARN] requires a database engine upgrade for cross-region replication support (Le cluster de bases de données [ARN du cluster de bases de données] nécessite une mise à jour du moteur de base de données pour la prise en charge de la réplication entre régions) Pour résoudre ce problème, mettez à niveau la version du moteur de base de données pour toutes les instances du cluster de bases de données source vers la version de moteur de base de données la plus récente, puis réessayez de créer une base de données de réplica en lecture entre régions. # Réplication entre Aurora et MySQL ou entre Aurora et un autre cluster de bases de données Aurora (réplication de journaux binaires) Comme Amazon Aurora MySQL est compatible avec MySQL, vous pouvez configurer la réplication entre une base de données MySQL et un cluster de bases de données Amazon Aurora MySQL. Ce type de réplication utilise la réplication du journal binaire MySQL et est également appelé *réplication de journaux binaires*. Si vous utilisez la réplication de journaux binaires avec Aurora, nous vous recommandons que votre base de données MySQL exécute MySQL version 5.5 ou ultérieure. Vous pouvez configurer la réplication où votre cluster de bases de données Aurora MySQL est la source de réplication ou le réplica. Vous pouvez répliquer avec une instance de base de données Amazon RDS MySQL, une base de données MySQL externe à Amazon RDS ou un autre cluster de bases de données Aurora MySQL. **Note** Vous ne pouvez pas utiliser la réplication des journaux binaires vers ou depuis certains types de clusters de bases de données Aurora. En particulier, la réplication des journaux binaires n’est pas disponible pour les clusters Aurora Serverless v1. Si l’instruction `SHOW MASTER STATUS` et `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3) ne renvoie aucune sortie, vérifiez que le cluster que vous utilisez prend en charge la réplication des journaux binaires. Vous pouvez aussi effectuer la réplication avec une instance de base de données RDS for MySQL ou un cluster de bases de données Aurora MySQL d’une autre Région AWS. Lorsque vous effectuez une réplication Régions AWS, assurez-vous que vos clusters de base de données et vos instances de base de données sont accessibles au public. Si les clusters de bases de données MySQL Aurora se trouvent dans des sous-réseaux privés de votre VPC, utilisez l’appairage de VPC entre les Régions AWS. Pour de plus amples informations, veuillez consulter [Un cluster de bases de données d’un VPC accessible par une instance EC2 d’un autre VPC](USER_VPC.Scenarios.md#USER_VPC.Scenario3). Si vous souhaitez configurer la réplication entre un cluster de base de données Aurora MySQL et un cluster de base de données Aurora MySQL dans un autre Région AWS, vous pouvez créer un cluster de base de données Aurora MySQL en tant que réplique en lecture dans un cluster de base de données Région AWS différent du cluster de base de données source. Pour de plus amples informations, veuillez consulter [Réplication de clusters de bases de données Amazon Aurora MySQL dans différentes Régions AWS](AuroraMySQL.Replication.CrossRegion.md). Avec les versions 2 et 3 d'Aurora MySQL, vous pouvez effectuer une réplication entre Aurora MySQL et une source ou une cible externe qui utilise des identificateurs de transaction globaux (GTIDs) pour la réplication. Vérifiez que les paramètres liés aux GTID dans le cluster de bases de données Aurora MySQL comportent des paramètres compatibles avec le statut GTID de la base de données externe. Pour savoir comment procéder, consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md). Dans Aurora MySQL version 3.01 et versions supérieures, vous pouvez choisir le mode d'attribution GTIDs des transactions répliquées à partir d'une source non utilisée. GTIDs Pour en savoir plus sur la procédure stockée qui contrôle ce paramètre, consultez [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL version 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). **Avertissement** Lorsque vous effectuez une réplication entre Aurora MySQL et MySQL, assurez-vous que vous n’utilisez que les tables InnoDB. Si vous souhaitez répliquer des tables MyISAM, vous pouvez les convertir en InnoDB avant de configurer la réplication avec la commande suivante. ``` alter table . engine=innodb, algorithm=copy; ``` Dans les sections suivantes, configurez la réplication, arrêtez la réplication, mettez à l’échelle les lectures pour votre base de données, optimisez la réplication des journaux binaires et configurez le journal binaire amélioré. **Topics** + [Configuration de la réplication des journaux binaires pour Aurora MySQL](AuroraMySQL.Replication.MySQL.SettingUp.md) + [Arrêt de la réplication des journaux binaires pour Aurora MySQL](AuroraMySQL.Replication.MySQL.Stopping.md) + [Mise à l’échelle des lectures pour votre base de données MySQL avec Amazon Aurora](AuroraMySQL.Replication.ReadScaling.md) + [Optimisation de la réplication des journaux binaires pour Aurora MySQL](binlog-optimization.md) + [Configuration du binlog amélioré pour Aurora MySQL](AuroraMySQL.Enhanced.binlog.md) # Configuration de la réplication des journaux binaires pour Aurora MySQL La configuration de la réplication MySQL avec Aurora MySQL implique les étapes suivantes, qui sont présentées en détail : **Contents** + [1. Activer la journalisation binaire sur la source de réplication](#AuroraMySQL.Replication.MySQL.EnableBinlog) + [2. Conserver les journaux binaires sur la source de réplication jusqu’à ce qu’ils ne soient plus nécessaires](#AuroraMySQL.Replication.MySQL.RetainBinlogs) + [3. Créer une copie ou un vidage de votre source de réplication](#AuroraMySQL.Replication.MySQL.CreateSnapshot) + [4. Charger le vidage dans votre cible de réplica (si nécessaire)](#AuroraMySQL.Replication.MySQL.LoadSnapshot) + [5. Créer un utilisateur de réplication sur votre source de réplication](#AuroraMySQL.Replication.MySQL.CreateReplUser) + [6. Activer la réplication sur votre cible de réplica](#AuroraMySQL.Replication.MySQL.EnableReplication) + [Définition d’une position où arrêter la réplication vers un réplica en lecture](#AuroraMySQL.Replication.StartReplicationUntil) + [7. Surveiller votre réplica](#AuroraMySQL.Replication.MySQL.Monitor) + [Synchronisation des mots de passe entre la source de réplication et la cible](#AuroraMySQL.Replication.passwords) ## 1. Activer la journalisation binaire sur la source de réplication Vous trouverez des instructions sur la façon d’activer la journalisation binaire sur la source de réplication pour votre moteur de base de données ci-après. | Moteur de base de données | Instructions | | --- | --- | | Aurora MySQL | **Pour activer la journalisation binaire sur un cluster de bases de données Aurora MySQL** Définissez le paramètre de cluster de bases de données `binlog_format` sur `ROW`, `STATEMENT` ou `MIXED`. La valeur `MIXED` est recommandée sauf si vous avez besoin d’un format de journal binaire spécifique. (La valeur par défaut est `OFF`.) Pour modifier le paramètre `binlog_format`, créez un groupe de paramètres de cluster de bases de données personnalisé et associez ce groupe de paramètres personnalisé à votre cluster de bases de données. Vous ne pouvez pas modifier les paramètres dans le groupe de paramètres de cluster de bases de données par défaut. Si vous modifiez le paramètre `binlog_format` en remplaçant `OFF` par une autre valeur, redémarrez votre cluster de bases de données Aurora pour que la modification prenne effet. Pour plus d’informations, consultez [Paramètres de cluster de bases de données et d’instance de base de données Amazon Aurora](USER_WorkingWithDBClusterParamGroups.md#Aurora.Managing.ParameterGroups) et [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). | | RDS for MySQL | **Pour activer la journalisation binaire sur une instance de base de données Amazon RDS** Vous ne pouvez pas activer la journalisation binaire directement pour une instance de base de données Amazon RDS, mais vous pouvez l’activer en exécutant l’une des actions suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (externe) | **Pour configurer la réplication chiffrée** Pour répliquer des données en toute sécurité avec Aurora MySQL version 2, vous pouvez utiliser la réplication chiffrée. Si vous n’avez pas besoin d’utiliser la réplication chiffrée, vous pouvez ignorer ces étapes. Pour pouvoir utiliser la réplication chiffrée, vous devez impérativement disposer des éléments suivants : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Pendant la réplication chiffrée, le cluster de bases de données Aurora MySQL agit comme client du serveur de base de données MySQL. Les certificats et les clés privées du client Aurora MySQL sont au format .pem dans les fichiers. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Pour activer la journalisation binaire sur une base de données MySQL externe** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 2. Conserver les journaux binaires sur la source de réplication jusqu’à ce qu’ils ne soient plus nécessaires Lorsque vous utilisez la réplication des journaux binaires MySQL, Amazon RDS ne gère pas le processus de réplication. En conséquence, vous devez vous assurer que les fichiers des journaux binaires sur votre source de réplication sont conservés jusqu’après que les modifications ont été appliquées au réplica. Cette maintenance vous permet de restaurer votre base de données source en cas de panne. Suivez les instructions suivantes pour conserver les journaux binaires de votre moteur de base de données. | Moteur de base de données | Instructions | | --- | --- | | Aurora MySQL | **Pour conserver les journaux binaires sur un cluster de bases de données Aurora MySQL** Vous n’avez pas accès aux fichiers journaux binaires pour un cluster de bases de données Aurora MySQL. En conséquence, vous devez choisir une période assez longue de conservation des fichiers journaux binaires sur votre source de réplication pour être assuré que les modifications ont été appliquées à votre réplica avant que le fichier journal binaire ne soit supprimé par Amazon RDS. Vous pouvez conserver les fichiers journaux binaires sur un cluster de bases de données Aurora MySQL pendant 90 jours maximum. Si vous configurez la réplication avec une base de données MySQL ou une instance de base de données RDS for MySQL comme réplica, et que la base de données pour laquelle vous créez un réplica est très volumineuse, choisissez une durée conséquente pour conserver les fichiers journaux binaires jusqu’à ce que la copie initiale de la base de données sur le réplica soit complète et que le retard du réplica ait atteint la valeur 0. Pour définir la période de rétention des journaux binaires, utilisez la procédure [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) et spécifiez un paramètre de configuration `'binlog retention hours'`, ainsi que le nombre d’heures pendant lequel conserver les fichiers journaux binaires sur le cluster de bases de données. La valeur maximum pour Aurora MySQL versions 2.11.0 et ultérieures et version 3 est 2 160 (90 jours). L’exemple suivant définit la période de rétention des fichiers journaux binaires sur 6 jours : 
CALL mysql.rds_set_configuration('binlog retention hours', 144);
Une fois la réplication démarrée, vous pouvez vérifier que les modifications ont été appliquées à votre réplica en exécutant la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3) sur votre réplica et en vérifiant le champ `Seconds behind master`. Si la valeur du champ `Seconds behind master` est 0, il n’y a pas de décalage de réplica. Quand il n’y a pas de retard du réplica, réduisez la période pendant laquelle les fichiers journaux binaires sont conservés en définissant le paramètre de configuration `binlog retention hours` sur une durée plus petite. Si ce paramètre n’est pas spécifié, la valeur par défaut pour Aurora MySQL est 24 (1 jour). Si vous spécifiez une valeur supérieure à la valeur maximale pour `'binlog retention hours'`, Aurora MySQL utilise la valeur maximale. | | RDS for MySQL | **Pour conserver les journaux binaires sur une instance de base de données Amazon RDS** Vous pouvez conserver les fichiers journaux binaires sur une instance de base de données Amazon RDS en définissant les heures de conservation des journaux binaires comme vous le feriez pour un cluster de bases de données Aurora MySQL (procédure décrite à la ligne précédente). Vous pouvez également conserver les fichiers journaux binaires sur une instance de base de données Amazon RDS en créant un réplica en lecture pour l’instance de base de données. Ce réplica en lecture a pour seul but temporaire et exclusif de conserver les fichiers journaux binaires. Une fois le réplica en lecture créé, appelez la procédure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) sur le réplica en lecture. Lorsque la réplication est arrêtée, Amazon RDS ne supprime aucun des fichiers journaux binaires sur la source de réplication. Après avoir configuré la réplication avec votre réplica permanent, vous pouvez supprimer le réplica en lecture lorsque le retard du réplica (champ `Seconds behind master`) entre votre source de réplication et votre réplica permanent atteint 0. | | MySQL (externe) | **Pour conserver les journaux binaires sur une base de données MySQL externe** Comme les fichiers journaux binaires sur une base de données MySQL externe ne sont pas gérés par Amazon RDS, ils sont conservés jusqu’à ce que vous les supprimiez. Une fois la réplication démarrée, vous pouvez vérifier que les modifications ont été appliquées à votre réplica en exécutant la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3) sur votre réplica et en vérifiant le champ `Seconds behind master`. Si la valeur du champ `Seconds behind master` est 0, il n’y a pas de décalage de réplica. Quand il n’y a pas de retard du réplica, vous pouvez supprimer les anciens fichiers journaux binaires. | ## 3. Créer une copie ou un vidage de votre source de réplication Vous utilisez un instantané, un clone ou un vidage de votre source de réplication pour charger une copie de référence de vos données sur votre réplica. Ensuite, vous commencez la réplication à partir de ce point. Utilisez les instructions suivantes pour créer une copie ou un vidage de votre source de réplication pour votre moteur de base de données. | Moteur de base de données | Instructions | | --- | --- | | Aurora MySQL | **Pour créer une copie d’un cluster de bases de données Aurora MySQL** Utilisez l’une des méthodes suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Pour déterminer le nom et la position du fichier binlog** Utilisez l’une des méthodes suivantes : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) **Pour créer un vidage d’un cluster de bases de données Aurora MySQL** Si votre cible de réplica est une base de données MySQL externe ou une instance de base de données RDS for MySQL, vous devez créer un fichier de vidage à partir de votre cluster de bases de données Aurora. Veillez bien à exécuter la commande `mysqldump` sur la copie du cluster de bases de données Aurora que vous avez créée. Cela permet d’éviter le verrouillage des tables sources lors du vidage. Si le vidage était effectué directement sur le cluster de bases de données source, il serait nécessaire de verrouiller ces tables pour empêcher les écritures simultanées pendant le vidage. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | RDS for MySQL | **Pour créer un instantané d’une instance de base de données Amazon RDS** Créez un réplica en lecture de votre instance de base de données Amazon RDS. Pour plus d’informations, consultez [Création d’un réplica en lecture](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html#USER_ReadRepl.Create) dans le *Guide de l’utilisateur Amazon Relational Database Service*. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (externe) | **Pour créer un vidage d’une base de données MySQL externe** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 4. Charger le vidage dans votre cible de réplica (si nécessaire) Si vous prévoyez de charger les données à partir d’un vidage d’une base de données MySQL externe à Amazon RDS, vous souhaiterez peut-être créer une instance EC2 sur laquelle copier les fichiers de vidage. Vous pourrez ensuite charger les données dans votre cluster de bases de données ou votre instance de base de données à partir de cette instance EC2. À l’aide de cette approche, vous pouvez compresser les fichiers de vidage avant de les copier sur l’instance EC2 afin de réduire les coûts réseau associés à la copie des données sur Amazon RDS. Vous pouvez aussi chiffrer les fichiers de vidage pour sécuriser les données tandis qu’elles sont transférées sur le réseau. **Note** Si vous créez un cluster de bases de données Aurora MySQL comme cible de réplica, vous n’avez pas besoin de charger un fichier de vidage : Vous pourrez ultérieurement restaurer un cluster de bases de données pour créer le cluster. Pour plus d’informations, consultez [Restauration à partir d’un instantané de cluster de bases de données](aurora-restore-snapshot.md). Vous pouvez cloner votre cluster de bases de données source pour créer un cluster de bases de données. Pour plus d’informations, consultez [Clonage d’un volume pour un cluster de bases de données Amazon Aurora](Aurora.Managing.Clone.md). Vous pouvez migrer les données d’un instantané d’instance de base de données vers un nouveau cluster de bases de données. Pour plus d’informations, consultez [Migration de données vers un cluster de bases de données Amazon Aurora MySQL](AuroraMySQL.Migrating.md). Utilisez les instructions suivantes pour charger le vidage de votre source de réplication dans votre cible de réplica pour votre moteur de base de données. | Moteur de base de données | Instructions | | --- | --- | | Aurora MySQL | **Pour charger un vidage dans un cluster de bases de données Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | RDS for MySQL | **Pour charger un vidage dans une instance de base de données Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | | MySQL (externe) | **Pour charger un vidage dans une base de données MySQL externe** Vous ne pouvez pas charger un instantané de base de données ou un instantané de cluster de bases de données dans une base de données MySQL externe. A la place, vous devez utiliser la sortie de la commande `mysqldump`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | ## 5. Créer un utilisateur de réplication sur votre source de réplication Créez un ID utilisateur sur la source qui est utilisé uniquement pour la réplication. L’exemple suivant concerne RDS for MySQL ou les bases de données sources MySQL externes. ``` mysql> CREATE USER 'repl_user'@'domain_name' IDENTIFIED BY 'password'; ``` Pour les bases de données source Aurora MySQL, le paramètre de cluster de bases de données `skip_name_resolve` est défini sur `1` (`ON`) et ne peut pas être modifié. Vous devez donc utiliser une adresse IP pour l’hôte au lieu d’un nom de domaine. Pour plus d’informations, consultez [skip\$1name\$1resolve](https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_skip_name_resolve) dans la documentation MySQL. ``` mysql> CREATE USER 'repl_user'@'IP_address' IDENTIFIED BY 'password'; ``` L’utilisateur nécessite les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE`. Accordez ces privilèges à l’utilisateur. Si vous avez besoin d’utiliser la réplication chiffrée, demandez des connexions SSL à l’utilisateur de la réplication. Par exemple, vous pouvez utiliser l’une des instructions suivantes pour demander les connexions SSL sur le compte d’utilisateur `repl_user`. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'IP_address'; ``` ``` GRANT USAGE ON *.* TO 'repl_user'@'IP_address' REQUIRE SSL; ``` **Note** Si `REQUIRE SSL` n’est pas inclus, la connexion de réplication peut revenir de façon silencieuse à une connexion non chiffrée. ## 6. Activer la réplication sur votre cible de réplica Avant d’activer la réplication, nous vous recommandons de prendre un instantané manuel du cluster de bases de données Aurora MySQL ou de la cible de réplica de l’instance de base de données RDS for MySQL. Si un problème survient et que vous avez besoin de rétablir la réplication avec la cible de réplica du cluster de bases de données ou de l’instance de base de données, vous pouvez restaurer le cluster de bases de données ou l’instance de base de données à partir de cet instantané au lieu de devoir importer à nouveau les données dans votre cible de réplica. Suivez les instructions suivantes pour activer la réplication pour votre moteur de base de données. | Moteur de base de données | Instructions | | --- | --- | | Aurora MySQL | **Pour activer la réplication à partir d’un cluster de bases de données Aurora MySQL** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Pour utiliser le chiffrement SSL, définissez la valeur finale sur `1` au lieu de `0`. | | RDS for MySQL | **Pour activer la réplication à partir d’une instance de base de données Amazon RDS** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) Pour utiliser le chiffrement SSL, définissez la valeur finale sur `1` au lieu de `0`. | | MySQL (externe) | **Pour activer la réplication à partir d’une base de données MySQL externe** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.SettingUp.html) | En cas d'échec de la réplication, cela peut entraîner une augmentation importante du nombre de répliques involontaires I/O , ce qui peut dégrader les performances. Si la réplication échoue ou n’est plus nécessaire, vous pouvez exécuter la procédure stockée [mysql.rds\$1reset\$1external\$1master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_master) ou [mysql.rds\$1reset\$1external\$1source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_reset_external_source) pour supprimer la configuration de réplication. ### Définition d’une position où arrêter la réplication vers un réplica en lecture Dans Aurora MySQL versions 3.04 et ultérieures, vous pouvez démarrer la réplication, puis l’arrêter à la position spécifiée dans le fichier journal binaire en utilisant la procédure stockée [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). **Pour démarrer la réplication vers un réplica en lecture et l’arrêter à une position donnée** 1. À l’aide d’un client MySQL, connectez-vous au cluster de bases de données Aurora MySQL du réplica en tant qu’utilisateur principal. 1. Exécutez la procédure stockée [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). L’exemple suivant lance la réplication et réplique les modifications jusqu’à ce qu’il atteigne la position `120` dans le fichier journal binaire `mysql-bin-changelog.000777`. Dans un scénario de reprise après sinistre, nous supposons que cette position `120` est juste avant le sinistre. ``` call mysql.rds_start_replication_until( 'mysql-bin-changelog.000777', 120); ``` La réplication s’arrête automatiquement lorsque le point d’arrêt est atteint. L’événement RDS suivant est généré: `Replication has been stopped since the replica reached the stop point specified by the rds_start_replication_until stored procedure`. Si vous utilisez une réplication basée sur des identifiants de transaction globaux (GTID), utilisez la procédure stockée [mysql.rds\$1start\$1replication\$1until\$1gtid (Aurora MySQL version 3)](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) au lieu de la procédure stockée [mysql.rds\$1start\$1replication\$1until (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Pour en savoir plus sur les réplications basées sur des identifiants de transaction globaux (GTID), consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md). ## 7. Surveiller votre réplica Lorsque vous configurez la réplication MySQL avec un cluster de bases de données Aurora MySQL, vous devez surveiller les événements de basculement du cluster de bases de données Aurora MySQL quand il s’agit de la cible de réplica. En cas de basculement, le cluster de bases de données qui est votre cible de réplica peut alors être recréé sur un nouvel hôte avec une adresse réseau différente. Pour plus d’informations sur la surveillance des événements de basculement, consultez [Utiliser la notification d’événements d’Amazon RDS](USER_Events.md). Vous pouvez aussi surveiller à quelle distance la cible de réplica se trouve de la source de réplication en vous connectant à la cible de réplica et en exécutant la commande `SHOW SLAVE STATUS` (Aurora MySQL version 2) ou `SHOW REPLICA STATUS` (Aurora MySQL version 3). Dans la sortie de la commande, le champ `Seconds Behind Master` vous indique à quelle distance la cible de réplica se trouve de la source de réplication. **Important** Si vous mettez à niveau votre cluster de bases de données et que vous spécifiez un groupe de paramètres personnalisé, assurez-vous de redémarrer manuellement le cluster une fois la mise à niveau terminée. Cela obligera le cluster à utiliser vos nouveaux paramètres personnalisés et redémarrera la réplication des journaux binaires. ## Synchronisation des mots de passe entre la source de réplication et la cible Lorsque vous modifiez des comptes d’utilisateur et des mots de passe sur la source de réplication à l’aide d’instructions SQL, ces modifications sont automatiquement répliquées sur la cible de réplication. Si vous utilisez l'API AWS Management Console AWS CLI, la ou l'API RDS pour modifier le mot de passe principal sur la source de réplication, ces modifications ne sont pas automatiquement répliquées sur la cible de réplication. Si vous souhaitez synchroniser l’utilisateur principal et le mot de passe principal entre les systèmes source et cible, vous devez effectuer vous-même la même modification sur la cible de réplication. # Arrêt de la réplication des journaux binaires pour Aurora MySQL Pour arrêter la réplication des journaux binaires avec une instance de base de données MySQL, une base de données MySQL externe ou un autre cluster Aurora DB, suivez les étapes présentées en détail dans la suite de cette rubrique. [1. Arrêter la réplication des journaux binaires sur la cible de réplica](#AuroraMySQL.Replication.MySQL.Stopping.StopReplication) [2. Désactiver la journalisation binaire sur la source de réplication](#AuroraMySQL.Replication.MySQL.Stopping.DisableBinaryLogging) ## 1. Arrêter la réplication des journaux binaires sur la cible de réplica Utilisez les instructions suivantes pour arrêter la réplication des journaux binaires pour votre moteur de base de données. | Moteur de base de données | Instructions | | --- | --- | | Aurora MySQL | **Pour arrêter la réplication des journaux binaires sur une cible de réplica de cluster de bases de données Aurora MySQL** Connectez-vous au cluster de bases de données Aurora qui est la cible de réplica et appelez la procédure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). | | RDS for MySQL | **Pour arrêter la réplication des journaux binaires sur une instance de base de données Amazon RDS** Connectez-vous à l’instance de base de données RDS qui est la cible de réplica et appelez la procédure [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication). | | MySQL (externe) | **Pour arrêter la réplication des journaux binaires sur une base de données MySQL externe** Connectez-vous à la base de données MySQL et exécutez la commande `STOP SLAVE` (version 5.7) ou `STOP REPLICA` (version 8.0). | ## 2. Désactiver la journalisation binaire sur la source de réplication Utilisez les instructions indiquées dans le tableau suivant pour désactiver la journalisation binaire sur la source de réplication pour votre moteur de base de données. | Moteur de base de données | Instructions | | --- | --- | | Aurora MySQL | **Pour désactiver la journalisation binaire sur un cluster de bases de données Amazon Aurora** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | | RDS for MySQL | **Pour désactiver la journalisation binaire sur une instance de base de données Amazon RDS** Vous ne pouvez pas désactiver la journalisation binaire directement pour une instance de base de données Amazon RDS, mais vous pouvez la désactiver en procédant comme suit : [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | | MySQL (externe) | **Pour désactiver la journalisation binaire sur une base de données MySQL externe** Connectez-vous à la base de données MySQL et appelez la commande `STOP REPLICATION`. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Replication.MySQL.Stopping.html) | # Mise à l’échelle des lectures pour votre base de données MySQL avec Amazon Aurora Vous pouvez utiliser Amazon Aurora avec votre instance de base de données MySQL pour tirer parti des capacités de mise à l’échelle en lecture d’Amazon Aurora et développer la charge de travail en lecture de votre instance de base de données MySQL. Pour utiliser Aurora afin de mettre à l’échelle les lectures pour votre instance de base de données MySQL, créez un cluster de bases de données Amazon Aurora MySQL et faites-en un réplica en lecture de votre instance de base de données MySQL. Cela s’applique à une instance de base de données RDS for MySQL ou à une base de données MySQL s’exécutant en dehors de Amazon RDS. Pour plus d’informations sur la création d’un cluster de bases de données Amazon Aurora, consultez [Création d’un cluster de bases de données Amazon Aurora](Aurora.CreateInstance.md). Lorsque vous configurez la réplication entre votre instance de base de données MySQL et votre cluster de bases de données Amazon Aurora, veillez à respecter les instructions suivantes : + Utilisez l’adresse du point de terminaison du cluster de bases de données Amazon Aurora lorsque vous référencez votre cluster de bases de données Amazon Aurora MySQL. Si un basculement se produit, le réplica Aurora qui est promu en instance principale du cluster de bases de données Aurora MySQL continue d’utiliser l’adresse du point de terminaison du cluster de bases de données. + Tenez à jour les journaux binaires sur votre instance d’enregistreur jusqu’à ce que vous ayez vérifié qu’ils ont été appliqués au réplica Aurora. Cela garantit que vous pouvez restaurer votre instance d’enregistreur en cas de défaillance. **Important** Lorsque vous utilisez une réplication auto-gérée, vous êtes chargé de surveiller et résoudre les problèmes de réplication éventuels. Pour plus d’informations, consultez [Diagnostic et résolution du retard entre réplicas en lecture](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.ReplicaLag). **Note** Les autorisations requises pour lancer la réplication sur un cluster de bases de données Aurora MySQL sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Par conséquent, vous devez utiliser les procédures [mysql.rds\$1set\$1external\$1master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour configurer la réplication entre votre cluster de bases de données Aurora MySQL et votre instance de base de données MySQL. ## Démarrer la réplication entre une instance source externe et un cluster de bases de données Aurora MySQL 1. Passez l’instance de base de données MySQL source en lecture seule : ``` mysql> FLUSH TABLES WITH READ LOCK; mysql> SET GLOBAL read_only = ON; ``` 1. Exécutez la commande `SHOW MASTER STATUS` sur l’instance de base de données MySQL source pour déterminer l’emplacement du journal binaire. Vous obtenez une sortie similaire à ce qui suit : ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` 1. Copiez la base de données de l’instance de base de données MySQL externe vers le cluster de bases de données Amazon Aurora MySQL à l’aide de `mysqldump`. Pour les bases de données très volumineuses, vous pouvez utiliser la procédure décrite dans la section [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/mysql-importing-data-reduced-downtime.html) du * Guide de l’utilisateur Amazon Relational Database Service*. Pour Linux, macOS ou Unix : ``` mysqldump \ --databases \ --single-transaction \ --compress \ --order-by-primary \ -u local_user \ -p local_password | mysql \ --host aurora_cluster_endpoint_address \ --port 3306 \ -u RDS_user_name \ -p RDS_password ``` Pour Windows : ``` mysqldump ^ --databases ^ --single-transaction ^ --compress ^ --order-by-primary ^ -u local_user ^ -p local_password | mysql ^ --host aurora_cluster_endpoint_address ^ --port 3306 ^ -u RDS_user_name ^ -p RDS_password ``` **Note** Veillez bien à ce qu’il n’y ait pas d’espace entre l’option `-p` et le mot de passe saisi. Utilisez les options `--host`, `--user (-u)`, `--port` et `-p` de la commande `mysql` pour spécifier le nom d’hôte, le nom d’utilisateur, le port et le mot de passe pour vous connecter à votre cluster de bases de données Aurora. Le nom d’hôte est le nom DNS du point de terminaison du cluster de bases de données Amazon Aurora, par exempl, `mydbcluster.cluster-123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans les détails de cluster dans Amazon RDS Management Console. 1. Transformez l’instance de base de données MySQL source en instance accessible de nouveau en écriture : ``` mysql> SET GLOBAL read_only = OFF; mysql> UNLOCK TABLES; ``` Pour plus d’informations sur les sauvegardes à utiliser avec la réplication, consultez [http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html](http://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html) dans la documentation MySQL. 1. Dans Amazon RDS Management Console, ajoutez l’adresse IP du serveur qui héberge la base de données MySQL source au groupe de sécurité VPC du cluster de bases de données Amazon Aurora. Pour plus d’informations sur la modification d’un groupe de sécurité de VPC, consultez [Groupes de sécurité pour votre VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) dans le *Guide de l’utilisateur Amazon Virtual Private Cloud*. Il se peut aussi que vous ayez besoin de configurer votre réseau local pour autoriser les connexions à partir de l’adresse IP de votre cluster de bases de données Amazon Aurora, de telle sorte qu’elle puisse communiquer avec votre instance MySQL source. Pour rechercher l’adresse IP du cluster de bases de données Amazon Aurora, utilisez la commande `host`. ``` host aurora_endpoint_address ``` Le nom d’hôte est le nom DNS du point de terminaison du cluster de bases de données Amazon Aurora. 1. À l’aide du client de votre choix, connectez-vous à l’instance MySQL externe et créez un utilisateur MySQL à utiliser pour la réplication. Ce compte est utilisé exclusivement pour la réplication et doit être limité à votre domaine pour améliorer la sécurité. Voici un exemple de. ``` CREATE USER 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Pour l’instance MySQL externe, attribuez les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` à votre utilisateur de réplication. Par exemple, pour accorder les privilèges `REPLICATION CLIENT` et `REPLICATION SLAVE` sur toutes les bases de données à l’utilisateur « `repl_user` » de votre domaine, émettez la commande suivante. ``` GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user'@'example.com' IDENTIFIED BY 'password'; ``` 1. Avant de configurer la réplication, prenez un instantané manuel du cluster de bases de données Aurora MySQL qui constituera le réplica en lecture. Si vous avez besoin de rétablir la réplication avec le cluster de bases de données en tant que réplica en lecture, vous pouvez restaurer le cluster de bases de données Aurora MySQL à partir de cet instantané au lieu de devoir importer les données depuis votre instance de base de données MySQL vers un nouveau cluster de bases de données Aurora MySQL. 1. Transformez le cluster de bases de données Amazon Aurora en réplica. Connectez-vous au cluster de bases de données Amazon Aurora en tant qu’utilisateur principal et identifiez la base de données MySQL source en tant que source de réplication en utilisant les procédures [mysql.rds\$1set\$1external\$1master (Aurora MySQL version 2)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (Aurora MySQL version 3)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). Utilisez le nom et la position du fichier binlog que vous avez déterminés à l’étape 2. Voici un exemple. ``` For Aurora MySQL version 2: CALL mysql.rds_set_external_master ('mymasterserver.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); For Aurora MySQL version 3: CALL mysql.rds_set_external_source ('mymasterserver.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 0); ``` 1. Sur le cluster de bases de données Amazon Aurora, appelez la procédure [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour démarrer la réplication. ``` CALL mysql.rds_start_replication; ``` Après avoir établi la réplication entre votre instance de base de données MySQL source et votre cluster de bases de données Amazon Aurora, vous pouvez ajouter des réplicas Aurora à votre cluster de bases de données Amazon Aurora. Vous pouvez alors vous connecter aux réplicas Aurora pour dimensionner vos données en lecture. Pour plus d’informations sur la création d’un réplica Aurora, consultez [Ajout de réplicas Aurora à un cluster de bases de données](aurora-replicas-adding.md). # Optimisation de la réplication des journaux binaires pour Aurora MySQL Découvrez ci-dessous comment optimiser les performances de réplication des journaux binaires et résoudre les problèmes connexes dans Aurora MySQL. **Astuce** Pour continuer, il est nécessaire de connaître le mécanisme de réplication de journaux binaires MySQL et son fonctionnement. Pour en savoir plus, consultez [Replication Implementation](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation.html) dans la documentation MySQL. ## Réplication des journaux binaires multithread Avec la réplication de journaux binaires multithreads, un thread SQL lit les événements du journal de relais et les met en file d’attente pour que les threads de travail SQL s’appliquent. Les threads de travail SQL sont gérés par un thread coordinateur. Si cela est possible, les événements du journal binaire sont appliqués en parallèle. Le niveau de parallélisme dépend de facteurs tels que la version, les paramètres, la conception du schéma et les caractéristiques de la charge de travail. La réplication multithread des journaux binaires est prise en charge dans Aurora MySQL version 3 et dans Aurora MySQL version 2.12.1 ou ultérieure. Pour qu’un réplica multithread traite efficacement les événements du journal binaire en parallèle, vous devez configurer la source pour la réplication des journaux binaires multithread. La source doit également utiliser une version qui inclut les informations de parallélisme sur ses fichiers journaux binaires. Lorsqu’une instance de base de données Aurora MySQL est configurée pour utiliser la réplication de journaux binaires, l’instance de réplica utilise par défaut la réplication à thread unique pour les versions d’Aurora MySQL inférieures à 3.04. Pour activer la réplication multithread, mettez à jour le paramètre `replica_parallel_workers` pour que sa valeur soit supérieure à `1` dans votre groupe de paramètres personnalisés. Pour Aurora MySQL 3.04 et versions ultérieures, la réplication est multithread par défaut. La valeur `replica_parallel_workers` est définie sur `4`. Vous pouvez modifier ce paramètre dans votre groupe de paramètres personnalisés. Pour augmenter la résilience de votre base de données face aux arrêts inattendus, nous vous recommandons d'activer la réplication GTID sur la source et d'autoriser GTIDs la réplication. Pour autoriser la réplication GTID, définissez `gtid_mode` sur `ON_PERMISSIVE` à la fois sur la source et le réplica. Pour en savoir plus sur les réplications basées sur des identifiants de transaction globaux (GTID), consultez [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md). Les options de configuration suivantes vous permettent d’optimiser la réplication multithread. Pour plus d’informations, consultez [Options et variables de réplication et de journalisation binaire](https://dev.mysql.com/doc/refman/8.0/en/replication-options.html) dans le *manuel de référence MySQL*. Pour plus d’informations sur la réplication multithread, consultez le blog MySQL [https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/](https://dev.mysql.com/blog-archive/improving-the-parallel-applier-with-writeset-based-dependency-tracking/). Les valeurs optimales des paramètres dépendent de plusieurs facteurs. Par exemple, les performances de la réplication des journaux binaires sont influencées par les caractéristiques de charge de travail de votre base de données, ainsi que la classe d’instance de base de données sur laquelle le réplica s’exécute. Dès lors, nous vous recommandons de tester minutieusement toutes les modifications apportées à ces paramètres de configuration avant d’appliquer de nouveaux paramètres à une instance de production : + `binlog_format recommended value` : défini sur `ROW` + `binlog_group_commit_sync_delay` + `binlog_group_commit_sync_no_delay_count` + `binlog_transaction_dependency_history_size` + `binlog_transaction_dependency_tracking` : la valeur recommandée est `WRITESET` + `replica_preserve_commit_order` + `replica_parallel_type` : la valeur recommandée est `LOGICAL_CLOCK` + `replica_parallel_workers` + `replica_pending_jobs_size_max` + `transaction_write_set_extraction` : la valeur recommandée est `XXHASH64` Les caractéristiques de votre schéma et de votre charge de travail sont des facteurs qui influent sur la réplication en parallèle. Les facteurs les plus courants sont les suivants. + Absence de clés primaires : RDS ne peut pas établir de dépendance entre les ensembles d’écritures pour les tables dépourvues de clés primaires. Avec le format `ROW`, une seule instruction à plusieurs lignes peut être exécutée avec une seule analyse de table complète au niveau de la source, mais il en résulte une analyse de table complète par ligne modifiée sur le réplica. L’absence de clés primaires réduit considérablement le débit de réplication. + Présence de clés étrangères : s’il existe des clés étrangères, Amazon RDS ne peut pas utiliser la dépendance entre les ensembles d’écritures pour le parallélisme des tables avec la relation FK. + Taille des transactions : si une seule transaction couvre des dizaines ou des centaines de mégaoctets ou de gigaoctets, le thread coordinateur et l’un des threads de travail peuvent passer beaucoup de temps à traiter uniquement cette transaction. Pendant ce temps, tous les autres threads de travail peuvent rester inactifs une fois qu’ils terminent le traitement de leurs transactions précédentes. Dans Aurora MySQL version 3.06 et versions ultérieures, vous pouvez améliorer les performances des réplicas de journaux binaires lors de la réplication des transactions pour de tables de grande taille comportant plusieurs index secondaires. Cette fonctionnalité introduit un groupe de threads permettant d’appliquer des modifications d’index secondaires en parallèle sur un réplica de journal binaire. Cette fonctionnalité est contrôlée par le paramètre de cluster de bases de données `aurora_binlog_replication_sec_index_parallel_workers`, qui contrôle le nombre total de threads parallèles disponibles pour appliquer les modifications d’index secondaires. Par défaut, ce paramètre est défini sur `0` (désactivé). L’activation de cette fonctionnalité ne nécessite pas le redémarrage de l’instance. Pour activer cette fonctionnalité, arrêtez la réplication en cours, définissez le nombre souhaité de threads de travail parallèles, puis relancez la réplication. ## Optimisation de la réplication des journaux binaires Dans Aurora MySQL 2.10 et versions ultérieures, Aurora applique automatiquement une optimisation connue sous le nom de I/O cache binlog à la réplication des journaux binaires. En mettant en cache les événements de journal binaire les plus récemment validés, cette optimisation est conçue pour améliorer les performances du thread de vidage des journaux binaires tout en limitant l’impact sur les transactions de premier plan sur l’instance source des journaux binaires. **Note** La mémoire utilisée pour cette fonction est indépendante du paramètre `binlog_cache` de MySQL. Cette fonction ne s’applique pas aux instances de base de données Aurora qui utilisent les classes d’instance `db.t2` et `db.t3`. Vous n’avez pas besoin d’ajuster les paramètres de configuration pour activer cette optimisation. En particulier, si vous aviez défini le paramètre de configuration `aurora_binlog_replication_max_yield_seconds` sur une valeur différente de zéro dans des versions antérieures d’Aurora MySQL, redéfinissez-le sur zéro pour les versions actuellement disponibles. Les variables `aurora_binlog_io_cache_reads` d'état vous `aurora_binlog_io_cache_read_requests` aident à surveiller la fréquence à laquelle les données sont lues à partir du I/O cache binlog. + `aurora_binlog_io_cache_read_requests`indique le nombre de demandes de I/O lecture du journal binaire depuis le cache. + `aurora_binlog_io_cache_reads`indique le nombre de I/O lectures du journal binaire qui extraient des informations du cache. La requête SQL suivante calcule le pourcentage de demandes de lecture de journaux binaires qui tirent parti des informations mises en cache. Dans ce cas, plus le ratio est proche de 100, mieux c’est. ``` mysql> SELECT (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_reads') / (SELECT VARIABLE_VALUE FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME='aurora_binlog_io_cache_read_requests') * 100 as binlog_io_cache_hit_ratio; +---------------------------+ | binlog_io_cache_hit_ratio | +---------------------------+ | 99.99847949080622 | +---------------------------+ ``` La fonctionnalité de I/O cache binlog inclut également de nouvelles métriques liées aux threads de vidage de binlog. Les *threads de vidage* sont les threads créés lorsque de nouveaux réplicas de journaux binaires sont connectés à l’instance source des journaux binaires. Les métriques de thread de vidage sont imprimées dans le journal de la base de données toutes les 60 secondes avec le préfixe `[Dump thread metrics]`. Les métriques incluent des informations pour chaque réplica de journal binaire, telles que `Secondary_id`, `Secondary_uuid`, le nom du fichier journal binaire et la position que chaque réplica est en train de lire. Les métriques incluent également `Bytes_behind_primary`, qui représente la distance en octets entre la source de réplication et le réplica. Cette métrique mesure le décalage du I/O thread de réplication. Cette figure est différente du décalage du thread d’application SQL du réplica, représenté par la métrique `seconds_behind_master` sur le réplica du journal binaire. Vous pouvez déterminer si les réplicas de journaux binaires rattrapent la source ou sont en retard en vérifiant si la distance diminue ou augmente. ## Journal de relais en mémoire Dans Aurora MySQL 3.10 et versions ultérieures, Aurora introduit une optimisation connue sous le nom de « journal de relais en mémoire » afin d’améliorer le débit de réplication. Cette optimisation améliore les I/O performances des journaux de relais en mettant en cache tout le contenu des journaux de relais intermédiaires en mémoire. Par conséquent, il réduit la latence de validation en minimisant les I/O opérations de stockage puisque le contenu du journal du relais reste facilement accessible en mémoire. Par défaut, la fonctionnalité de journal de relais en mémoire est automatiquement activée pour les scénarios de réplication gérés par Aurora (y compris les déploiements bleu-vert, la réplication Aurora/Aurora et les réplicas entre régions) lorsque le réplica répond à l’une des configurations suivantes : + Mode de réplication à thread unique (replica\$1parallel\$1workers = 0) + Réplication multithread avec le mode GTID activé : + Positionnement automatique activé + Mode GTID activé sur le réplica + Réplication basée sur des fichiers avec replica\$1preserve\$1commit\$1order = ON La fonctionnalité de journal de relais en mémoire est prise en charge sur les classes d’instance supérieures à t3.large, mais n’est pas disponible sur les instances Aurora Serverless. La mémoire tampon circulaire du journal de relais a une taille fixe de 128 Mo. Pour contrôler la consommation de mémoire de cette version, vous pouvez exécuter la requête suivante : ``` SELECT event_name, current_alloc FROM sys.memory_global_by_current_bytes WHERE event_name = 'memory/sql/relaylog_io_cache'; ``` La fonctionnalité de journal de relais en mémoire est contrôlée par le paramètre aurora\$1in\$1memory\$1relaylog, qui peut être défini au niveau du cluster de bases de données ou de l’instance de base de données. Vous pouvez activer ou désactiver cette version de manière dynamique sans avoir à redémarrer l’instance : 1. Arrêt de la réplication en cours 1. Définissez aurora\$1in\$1memory\$1relaylog sur ON (pour l’activer) ou OFF (pour le désactiver) dans le groupe de paramètres. 1. Redémarrage de la réplication Exemple : ``` CALL mysql.rds_stop_replication; set aurora_in_memory_relaylog to ON to enable or OFF to disable in cluster parameter group CALL mysql.rds_start_replication; ``` Même quand aurora\$1in\$1memory\$1relaylog est activé, la fonctionnalité de journal de relais en mémoire peut toujours être désactivée dans certaines conditions. Pour vérifier l’état actuel de cette fonctionnalité, vous pouvez utiliser la commande suivante : ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_status'; ``` Si la fonctionnalité est désactivée de façon inattendue, vous pouvez en identifier la raison en exécutant : ``` SHOW GLOBAL STATUS LIKE 'Aurora_in_memory_relaylog_disabled_reason'; ``` Cette commande renvoie un message expliquant pourquoi la fonctionnalité est actuellement désactivée. # Configuration du binlog amélioré pour Aurora MySQL Le binlog amélioré réduit la surcharge de performances de calcul provoquée par l’activation de binlog, qui peut atteindre 50 % dans certains cas. Avec le binlog amélioré, cette surcharge peut être réduite à environ 13 %. Pour réduire la surcharge, le binlog amélioré écrit les journaux binaires et de transactions sur le stockage en parallèle, ce qui minimise les données écrites au moment de la validation de la transaction. L’utilisation d’un binlog amélioré améliore également le temps de récupération de la base de données après les redémarrages et les basculements de 99 % par rapport au binlog MySQL communautaire. Le binlog amélioré est compatible avec les charges de travail existantes basées sur binlog et vous interagissez avec lui de la même manière que vous interagissez avec le binlog MySQL communautaire. Le binlog amélioré est disponible sur les versions Aurora MySQL 3.03.1 et ultérieures. **Topics** + [Configuration des paramètres d’un binlog amélioré](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters) + [Autres paramètres connexes](#AuroraMySQL.Enhanced.binlog.other.parameters) + [Différences entre le binlog amélioré et le binlog MySQL communautaire](#AuroraMySQL.Enhanced.binlog.differences) + [Métriques Amazon CloudWatch pour le binlog amélioré](#AuroraMySQL.Enhanced.binlog.cloudwatch.metrics) + [Limites du binlog amélioré](#AuroraMySQL.Enhanced.binlog.limitations) ## Configuration des paramètres d’un binlog amélioré Vous pouvez basculer entre le binlog MySQL communautaire et le binlog amélioré en activant/désactivant les paramètres du binlog amélioré. Les utilisateurs existants de binlog peuvent continuer à lire et à utiliser les fichiers binlog sans aucune interruption dans la séquence des fichiers binlog. Pour activer le binlog amélioré, définissez les paramètres suivants : | Paramètre | Par défaut | Description | | --- | --- | --- | | binlog\$1format | – | Définissez le paramètre binlog\$1format au format de journalisation binaire de votre choix pour activer le binlog amélioré. Assurez-vous que le binlog\$1format parameter n’est pas réglé sur OFF. Pour plus d’informations, consultez [Configuration de la journalisation binaire Aurora MySQL](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_LogAccess.MySQL.BinaryFormat.html). | | aurora\$1enhanced\$1binlog | 0 | Définissez la valeur de ce paramètre sur 1 dans le groupe de paramètres du cluster de bases de données associé au cluster Aurora MySQL. Lorsque vous modifiez la valeur de ce paramètre, vous devez redémarrer l’instance de rédacteur lorsque la valeur DBClusterParameterGroupStatus est affichée comme pending-reboot. | | binlog\$1backup | 1 | Désactivez ce paramètre pour activer le binlog amélioré. Pour ce faire, définissez la valeur de ce paramètre sur 0. | | binlog\$1replication\$1globaldb | 1 | Désactivez ce paramètre pour activer le binlog amélioré. Pour ce faire, définissez la valeur de ce paramètre sur 0. | **Important** Vous ne pouvez désactiver les paramètres `binlog_backup` et `binlog_replication_globaldb` que lorsque vous utilisez le binlog amélioré. Pour désactiver le journal binaire amélioré, définissez les paramètres suivants : | Paramètre | Description | | --- | --- | | aurora\$1enhanced\$1binlog | Définissez la valeur de ce paramètre sur 0 dans le groupe de paramètres du cluster de bases de données associé au cluster Aurora MySQL. À chaque fois que vous modifiez la valeur de ce paramètre, vous devez redémarrer l’instance de rédacteur lorsque la valeur DBClusterParameterGroupStatus est affichée comme pending-reboot. | | binlog\$1backup | Activez ce paramètre lorsque vous désactivez le binlog amélioré. Pour ce faire, définissez la valeur de ce paramètre sur 1. | | binlog\$1replication\$1globaldb | Activez ce paramètre lorsque vous désactivez le binlog amélioré. Pour ce faire, définissez la valeur de ce paramètre sur 1. | Pour vérifier si le binlog amélioré est activé, utilisez la commande suivante dans le client MySQL : ``` mysql>show status like 'aurora_enhanced_binlog'; +------------------------+--------+ | Variable_name | Value | +------------------------+--------+ | aurora_enhanced_binlog | ACTIVE | +------------------------+--------+ 1 row in set (0.00 sec) ``` Lorsque le binlog amélioré est activé, la sortie affiche `ACTIVE` pour`aurora_enhanced_binlog`. ## Autres paramètres connexes Lorsque vous activez le binlog amélioré, les paramètres suivants sont affectés : + Le paramètre `max_binlog_size` est visible mais non modifiable. Sa valeur par défaut `134217728` est automatiquement ajustée sur `268435456` lorsque le binlog amélioré est activé. + Contrairement au binlog MySQL communautaire, `binlog_checksum` n’agit pas comme un paramètre dynamique lorsque le binlog amélioré est activé. Pour que la modification de ce paramètre soit prise en compte, vous devez redémarrer manuellement le cluster de bases de données, même si la `ApplyMethod` est `immediate`. + La valeur que vous définissez sur le paramètre `binlog_order_commits` n’a aucun effet sur l’ordre des validations lorsque le binlog amélioré est activé. Les validations sont toujours ordonnées sans aucune autre incidence sur les performances. ## Différences entre le binlog amélioré et le binlog MySQL communautaire Le binlog amélioré interagit différemment avec les clones, les sauvegardes et la base de données globale Aurora par rapport au binlog MySQL communautaire. Nous vous recommandons de comprendre les différences suivantes avant d’utiliser le binlog amélioré. + Les fichiers binlog améliorés du cluster de bases de données source ne sont pas disponibles sur un cluster de bases de données cloné. + Les fichiers binlog améliorés ne sont pas inclus dans les sauvegardes Aurora. Par conséquent, les fichiers binlog améliorés du cluster de bases de données source ne sont pas disponibles après la restauration d’un cluster de bases de données, même avec une période de conservation définie. + Lorsqu’ils sont utilisés avec une base de données globale Aurora, les fichiers binlog améliorés du cluster de bases de données principal ne sont pas répliqués vers le cluster de bases de données des régions secondaires. ****Exemples**** Les exemples suivants montrent les différences entre le binlog amélioré et le binlog MySQL communautaire. **Sur un cluster de bases de données restauré ou cloné** Lorsque le binlog amélioré est activé, les fichiers binlog historiques ne sont pas disponibles dans le cluster de bases de données restauré ou cloné. Après une opération de restauration ou de clonage, si le binlog est activé, le nouveau cluster de bases de données commence à écrire sa propre séquence de fichiers binlog, en commençant par 1 (mysql-bin-changelog.000001). Pour activer le binlog amélioré après une opération de restauration ou de clonage, définissez les paramètres du cluster de bases de données requis sur le cluster de bases de données restauré ou cloné. Pour plus d’informations, consultez [Configuration des paramètres d’un binlog amélioré](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters). **Example Exemple : opération de clonage ou de restauration effectuée lorsque le binlog amélioré est activé** Cluster de bases de données source : ``` mysql> show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | | mysql-bin-changelog.000003 | 156 | No | | mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog turned on | mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog turned on | mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog turned on +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` Sur un cluster de bases de données restauré ou cloné, les fichiers binlog ne sont pas sauvegardés lorsque le journal binaire amélioré est activé. Pour éviter toute discontinuité dans les données du binlog, les fichiers binlog écrits avant l’activation du binlog amélioré ne sont pas non plus disponibles. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | --> New sequence of Binlog files +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Example Exemple : opération de clonage ou de restauration effectuée lorsque le binlog amélioré est désactivé** Cluster de bases de données source : ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` Le journal binaire amélioré est désactivé après `mysql-bin-changelog.000003`. Sur un cluster de bases de données restauré ou cloné, les fichiers binlog écrits après la désactivation du binlog amélioré sont disponibles. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Sur une Amazon Aurora Global Database** Sur une Amazon Aurora Global Database, les données du binlog du cluster de bases de données principal ne sont pas répliquées vers les clusters de bases de données secondaires. Après un processus de basculement entre régions, les données du binlog ne sont pas disponibles dans le cluster de bases de données principal récemment promu. Si le binlog est activé, le nouveau cluster de bases de données récemment promu commence sa propre séquence de fichiers binlog, en commençant par 1 (mysql-bin-changelog.000001). Pour activer le binlog amélioré après un basculement, vous devez définir les paramètres de cluster de bases de données requis sur le cluster de bases de données secondaire. Pour plus d’informations, consultez [Configuration des paramètres d’un binlog amélioré](#AuroraMySQL.Enhanced.binlog.enhancedbinlog.parameters). **Example Exemple : l’opération de basculement global de la base de données est effectuée lorsque le binlog amélioré est activé** Ancien cluster de bases de données principal (avant le basculement) : ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | | mysql-bin-changelog.000003 | 156 | No | | mysql-bin-changelog.000004 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000005 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000006 | 156 | No | --> Enhanced Binlog enabled +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` Nouveau cluster de bases de données principal (après le basculement) : Les fichiers binlog ne sont pas répliqués vers les régions secondaires lorsque le binlog amélioré est activé. Pour éviter toute discontinuité dans les données du binlog, les fichiers binlog écrits avant l’activation du binlog amélioré ne sont pas disponibles. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | --> Fresh sequence of Binlog files +----------------------------+-----------+-----------+ 1 row in set (0.00 sec) ``` **Example Exemple : l’opération de basculement global de la base de données est effectuée lorsque le binlog amélioré est désactivé** Cluster de bases de données source : ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000001 | 156 | No | | mysql-bin-changelog.000002 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000003 | 156 | No | --> Enhanced Binlog enabled | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 6 rows in set (0.00 sec) ``` **Cluster de bases de données restauré ou cloné :** Le journal binaire amélioré est désactivé après `mysql-bin-changelog.000003`. Les fichiers binlog qui sont écrits après la désactivation du binlog amélioré sont répliqués et sont disponibles dans le cluster de bases de données récemment promu. ``` mysql>show binary logs; +----------------------------+-----------+-----------+ | Log_name | File_size | Encrypted | +----------------------------+-----------+-----------+ | mysql-bin-changelog.000004 | 156 | No | | mysql-bin-changelog.000005 | 156 | No | | mysql-bin-changelog.000006 | 156 | No | +----------------------------+-----------+-----------+ 3 rows in set (0.00 sec) ``` ## Métriques Amazon CloudWatch pour le binlog amélioré Les métriques Amazon CloudWatch suivantes sont publiées uniquement lorsque le binlog amélioré est activé. | Métrique CloudWatch | Description | Unités | | --- | --- | --- | | ChangeLogBytesUsed | Volume de stockage utilisé par le binlog amélioré. | Octets | | ChangeLogReadIOPs | Nombre d’opérations d’E/S de lecture réalisées dans le binlog amélioré à 5 minutes d’intervalles. | Compte par 5 minutes | | ChangeLogWriteIOPs | Nombre d’opérations d’E/S d’écriture disque réalisées dans le binlog amélioré à 5 minutes d’intervalles. | Compte par 5 minutes | ## Limites du binlog amélioré Les limites suivantes s’appliquent aux clusters de bases de données Amazon Aurora lorsque le binlog amélioré est activé. + Le binlog amélioré est uniquement pris en charge sur les versions Aurora MySQL 3.03.1 et ultérieures. + Les fichiers binlog améliorés écrits sur le cluster de bases de données principal ne sont pas copiés vers les clusters de bases de données clonés ou restaurés. + Lorsqu’ils sont utilisés avec Amazon Aurora Global Database, les fichiers binlog améliorés du cluster de bases de données principal ne sont pas répliqués vers les clusters de bases de données secondaires. Par conséquent, après le processus de basculement, les données historiques du binlog ne sont pas disponibles dans le nouveau cluster de bases de données principal. + Les paramètres de configuration du binlog suivants sont ignorés : + `binlog_group_commit_sync_delay` + `binlog_group_commit_sync_no_delay_count` + `binlog_max_flush_queue_time` + Vous ne pouvez pas supprimer ou renommer une table corrompue dans une base de données. Pour supprimer ces tables, vous pouvez contacter Support. + Le cache d’E/S du binlog est désactivé lorsque le binlog amélioré est activé. Pour plus d’informations, consultez [Optimisation de la réplication des journaux binaires pour Aurora MySQL](binlog-optimization.md). **Note** Le binlog amélioré fournit de meilleures performances de lecture similaires à celles du cache d’E/S du binlog et de meilleures performances d’écriture. + La fonction de retour en arrière n’est pas prise en charge. Le binlog amélioré ne peut pas être activé dans un cluster de bases de données dans les conditions suivantes : + Cluster de bases de données avec la fonctionnalité de retour en arrière actuellement activée. + Cluster de bases de données avec la fonctionnalité de retour en arrière précédemment activée mais maintenant désactivée. + Cluster de bases de données restauré à partir d’un cluster de bases de données source ou d’un instantané avec la fonction de retour en arrière activée. # Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID) Le contenu ci-dessous explique comment utiliser les identifiants de transaction globaux (GTID) avec la réplication des journaux binaires (binlog) entre un cluster Aurora MySQL et une source externe. **Note** Pour Aurora, vous pouvez uniquement utiliser cette fonction avec des clusters Aurora MySQL qui utilisent la réplication des journaux binaires vers/à partir d’une base de données MySQL externe. L’autre base de données peut être une instance Amazon RDS MySQL, une base de données MySQL sur site, ou un cluster de bases de données Aurora dans une autre Région AWS. Pour apprendre à configurer ce type de réplication, 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)](AuroraMySQL.Replication.MySQL.md). Si vous utilisez la réplication des journaux binaires, mais que vous ne maîtrisez pas la réplication GTID avec MySQL, consultez [Réplication avec des identifiants de transaction globaux](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids.html) dans la documentation MySQL. La réplication GTID est prise en charge pour Aurora MySQL versions 2 et 3. **Topics** + [Présentation des identifiants de transaction globaux (GTID)](#mysql-replication-gtid.overview) + [Paramètres pour la réplication basée sur des identifiants de transaction globaux (GTID)](#mysql-replication-gtid.parameters) + [Activation de la réplication GTID pour un cluster Aurora MySQL](mysql-replication-gtid.configuring-aurora.md) + [Désactivation de la réplication GTID pour un cluster de bases de données Aurora MySQL](mysql-replication-gtid.disabling.md) ## Présentation des identifiants de transaction globaux (GTID) Les *identifiants de transaction globaux (GTID)* sont des identifiants uniques générés pour des transactions MySQL validées. Vous pouvez utiliser ces identifiants pour simplifier et faciliter la résolution des problèmes liés à la réplication des journaux binaires. **Note** Lorsqu’Aurora synchronise des données entre les instances de base de données d’un cluster, ce mécanisme de réplication n’implique pas le journal binaire (binlog). Pour Aurora MySQL, la réplication GTID s’applique uniquement lorsque vous utilisez également la réplication des journaux binaires pour répliquer à l’intérieur ou à l’extérieur d’un cluster de bases de données Aurora MySQL à partir d’une base de données externe compatible avec MySQL. MySQL utilise deux types différents de transactions pour la réplication des journaux binaires : + *Transactions GTID* – Transactions identifiées par un identifiant de transaction global (GTID). + *Transactions anonymes* – Transactions auxquelles aucun identifiant de transaction global (GTID) n’est associé. Dans une configuration de réplication, les GTID sont uniques parmi toutes les instances de base de données. Les GTID simplifient la configuration de réplication dans la mesure où, lorsque vous les utilisez, vous n’avez pas à vous référer aux positions des fichiers journaux. Les GTID facilitent également le suivi des transactions répliquées et déterminent si l’instance source et les réplicas sont cohérents. En règle générale, vous utilisez la réplication GTID avec Aurora lorsque vous effectuez une réplication à partir d’une base de données externe compatible avec MySQL dans un cluster Aurora. Vous pouvez procéder à la configuration de cette réplication dans le cadre d’une migration d’une base de données sur site ou Amazon RDS vers Aurora MySQL. Si la base de données externe utilise déjà des identifiants de transaction globaux (GTID), l’utilisation de la réplication GTID pour le cluster Aurora permet de simplifier le processus de réplication. Vous configurez la réplication GTID pour un cluster Aurora MySQL en commençant par définir les paramètres de configuration appropriés dans un groupe de paramètres de cluster de bases de données. Vous associez ensuite ce groupe de paramètres au cluster. ## Paramètres pour la réplication basée sur des identifiants de transaction globaux (GTID) Utilisez les paramètres suivants pour configurer une réplication GTID. | Paramètre | Valeurs valides | Description | | --- | --- | --- | | `gtid_mode` | `OFF`, `OFF_PERMISSIVE`, `ON_PERMISSIVE`, `ON` | `OFF` spécifie que les nouvelles transactions sont des transactions anonymes (et n’ont donc pas de GTID), et qu’une transaction doit être anonyme pour être répliquée. `OFF_PERMISSIVE` spécifie que les nouvelles transactions sont des transactions anonymes, mais que toutes les transactions peuvent être répliquées. `ON_PERMISSIVE` spécifie que les nouvelles transactions sont des transactions GTID, mais que toutes les transactions peuvent être répliquées. `ON` spécifie que les nouvelles transactions sont des transactions GTID, et qu’une transaction doit être une transaction GTID pour être répliquée. | | `enforce_gtid_consistency` | `OFF`, `ON`, `WARN` | `OFF` autorise les transactions à enfreindre la cohérence GTID. `ON` interdit aux transactions d’enfreindre la cohérence GTID. `WARN` autorise les transactions à enfreindre la cohérence GTID mais génère un avertissement lorsqu’une infraction se produit. | **Note** Dans AWS Management Console, le paramètre `gtid_mode` apparaît sous la forme `gtid-mode`. Pour la réplication GTID, utilisez ces paramètres pour le groupe de paramètres de votre cluster de bases de données Aurora MySQL : + `ON` et `ON_PERMISSIVE` s’appliquent uniquement à la réplication sortante d’un cluster Aurora MySQL. Ces deux valeurs forcent votre cluster de base de données Aurora à utiliser des identifiants de transaction globaux (GTID) pour les transactions répliquées sur une base de données externe. `ON` exige que la base de données externe utilise également la réplication GTID. `ON_PERMISSIVE` rend la réplication GTID facultative sur la base de données externe. + S’il est défini, `OFF_PERMISSIVE` indique que votre cluster de bases de données Aurora peuvent accepter la réplication entrante à partir d’une base de données externe. que cette dernière utilise la réplication GTID ou non. + S’il est défini, `OFF` indique que votre cluster de bases de données Aurora accepte uniquement la réplication entrante à partir de bases de données externes qui n’utilisent pas la réplication GTID. **Astuce** La réplication entrante est le scénario de réplication des journaux binaires le plus fréquent pour les clusters Aurora MySQL. Pour la réplication entrante, il est recommandé de définir le mode GTID sur `OFF_PERMISSIVE`. Cette valeur autorise la réplication entrante à partir de bases de données externes, quels que soient les paramètres GTID au niveau de la source de réplication. Pour plus d’informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). # Activation de la réplication GTID pour un cluster Aurora MySQL Lorsque la réplication GTID est activée pour un cluster de bases de données Aurora MySQL, les paramètres GTID s’appliquent à la réplication  des journaux binaires entrante et sortante. **Pour activer la réplication GTID pour un cluster Aurora MySQL** 1. Créez ou modifiez un groupe de paramètres de cluster de bases de données en définissant les valeurs suivantes : + `gtid_mode` – `ON` ou `ON_PERMISSIVE` + `enforce_gtid_consistency` – `ON` 1. Associez le groupe de paramètres de cluster de bases de données au cluster Aurora MySQL. Pour ce faire, suivez les procédures décrites dans [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). 1. (Facultatif) Indiquez comment affecter des GTID à des transactions qui n’en incluent pas. Pour ce faire, appelez la procédure stockée dans [mysql.rds\$1assign\$1gtids\$1to\$1anonymous\$1transactions (Aurora MySQL version 3)](mysql-stored-proc-gtid.md#mysql_assign_gtids_to_anonymous_transactions). # Désactivation de la réplication GTID pour un cluster de bases de données Aurora MySQL Vous pouvez désactiver la réplication GTID pour un cluster de bases de données Aurora MySQL. Dans ce cas, le cluster Aurora ne peut pas effectuer de réplication des journaux binaires entrante ou sortante avec des bases de données externes qui utilisent la réplication GTID. **Note** Dans la procédure suivante, un *réplica en lecture* représente la cible de réplication dans une configuration Aurora avec une réplication des journaux binaires vers/à partir d’une base de données externe. Il ne représente pas les instances de base de données de réplica Aurora en lecture seule. Par exemple, lorsqu’un cluster Aurora accepte la réplication entrante à partir d’une source externe, l’instance principale d’Aurora sert de réplica en lecture pour la réplication des journaux binaires. Pour plus de détails sur les procédures stockées mentionnées dans la présente section, veuillez consulter [Référence des procédures stockées Aurora MySQL](AuroraMySQL.Reference.StoredProcs.md). **Pour désactiver la réplication GTID pour un cluster de bases de données Aurora MySQL** 1. Sur les réplicas Aurora, exécutez la procédure suivante : Pour la version 3 ``` CALL mysql.rds_set_source_auto_position(0); ``` Pour la version 2 ``` CALL mysql.rds_set_master_auto_position(0); ``` 1. Réinitialisez `gtid_mode` sur `ON_PERMISSIVE`. 1. Assurez-vous que le groupe de paramètres de cluster de bases de données associé au cluster Aurora MySQL contient le paramètre `gtid_mode` défini sur `ON_PERMISSIVE`. Pour plus d’informations sur la définition des paramètres de configuration à l’aide de groupes de paramètres, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). 1. Redémarrez le cluster de bases de données Aurora MySQL. 1. Réinitialisez `gtid_mode` sur `OFF_PERMISSIVE`. 1. Assurez-vous que le groupe de paramètres de cluster de bases de données associé au cluster Aurora MySQL contient le paramètre `gtid_mode` défini sur `OFF_PERMISSIVE`. 1. Redémarrez le cluster de base de données Aurora MySQL. 1. Attendez que toutes les transactions GTID soient appliquées sur l’instance principale d’Aurora. Pour vérifier qu’elles ont été appliquées, procédez comme suit : 1. Sur l’instance Auroraprincipale, exécutez la commande `SHOW MASTER STATUS`. Votre sortie doit ressembler à ce qui suit. ``` File Position ------------------------------------ mysql-bin-changelog.000031 107 ------------------------------------ ``` Notez le fichier et la position dans votre sortie. 1. Sur chaque réplica en lecture, utilisez les informations de fichier et de position de l’instance source lors de l’étape précédente pour exécuter la requête suivante : Pour la version 3 ``` SELECT SOURCE_POS_WAIT('file', position); ``` Pour la version 2 ``` SELECT MASTER_POS_WAIT('file', position); ``` Par exemple, si votre fichier se nomme `mysql-bin-changelog.000031` et que sa position est `107`, exécutez l’instruction suivante : Pour la version 3 ``` SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107); ``` Pour la version 2 ``` SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107); ``` 1. Réinitialisez les paramètres GTID pour désactiver la réplication GTID. 1. Assurez-vous que le groupe de paramètres de cluster de bases de données associé au cluster Aurora MySQL contient les valeurs suivantes : + `gtid_mode` – `OFF` + `enforce_gtid_consistency` – `OFF` 1. Redémarrez le cluster de base de données Aurora MySQL.