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.
# Utilisation de la réplication MySQL dans Amazon RDS
Vous utilisez généralement des réplicas en lecture pour configurer la réplication entre instances de base de données Amazon RDS. Pour obtenir des informations générales sur les réplicas en lecture, consultez [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md). Pour obtenir des informations spécifiques sur l'utilisation des réplicas en lecture sur Amazon RDS pour MySQL, consultez la section [Utilisation de réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.md).
Vous pouvez utiliser des identificateurs de transaction globaux (GTIDs) pour la réplication avec RDS for MySQL. Pour de plus amples informations, veuillez consulter [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
Vous pouvez également configurer la réplication entre une instance de base de données RDS for MySQL et une instance MariaDB ou MySQL externe à Amazon RDS. Pour plus d'informations sur la réplication de configuration avec une source externe, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
Pour chacune de ces options de réplication, vous pouvez utiliser la réplication basée sur les lignes, basée sur les instructions ou mixte. La réplication basée sur les lignes réplique uniquement les lignes modifiées à la suite d'une instruction SQL. La réplication basée sur les instructions réplique l'ensemble de l'instruction SQL. La réplication mixte utilise la réplication basée sur les instructions chaque fois que possible, mais bascule vers la réplication basée sur les lignes lorsque des instructions SQL présentant un risque pour la réplication basée sur les instructions sont exécutées. La réplication mixte est recommandée dans la plupart des cas. Le format de journalisation binaire de l'instance de base de données détermine si la réplication est basée sur les lignes, basée sur les instructions ou mixte. Pour plus d'informations sur la définition du format de journalisation binaire, consultez la section [Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md).
**Note**
Vous pouvez configurer la réplication de sorte à importer des bases de données d'une instance MariaDB ou MySQL extérieure à Amazon RDS, ou à exporter des bases de données vers de telles instances. Pour plus d’informations, consultez [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md) et [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
Après avoir restauré votre instance de base de données à partir d'un instantané ou effectué une point-in-time restauration, vous pouvez consulter la dernière position du journal binaire récupérée depuis la base de données source dans la console RDS. Sous **Journaux et événements**, saisissez **journal binaire**. La position du journal binaire apparaît sous **Remarques relatives au système**.
**Topics**
+ [
# Utilisation de réplicas en lecture MySQL
](USER_MySQL.Replication.ReadReplicas.md)
+ [
# Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)
](mysql-replication-gtid.md)
+ [
# Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
](MySQL.Procedural.Importing.External.Repl.md)
+ [
# Configuration multi-source-replication pour Amazon RDS for MySQL
](mysql-multi-source-replication.md)
# Utilisation de réplicas en lecture MySQL
Vous trouverez à la suite des informations spécifiques sur l'utilisation des réplicas en lecture sur RDS for MySQL. Pour obtenir des informations générales sur les réplicas en lecture et des instructions pour les utiliser, veuillez consulter [Utilisation des réplicas en lecture d'instance de base de données](USER_ReadRepl.md).
Pour plus d’informations sur l’utilisation des réplicas en lecture MySQL, consultez les rubriques suivantes.
+ [Configuration des filtres de réplication avec MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md)
+ [Configuration de la réplication retardée avec MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md)
+ [Mise à jour des réplicas en lecture avec MySQL](USER_MySQL.Replication.ReadReplicas.Updates.md)
+ [Utiliser des déploiements de réplicas en lecture Multi-AZ avec MySQL](USER_MySQL.Replication.ReadReplicas.MultiAZ.md)
+ [Utilisation de réplicas en lecture en cascade avec RDS for MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md)
+ [Surveillance du retard de réplication pour les réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.Monitor.md)
+ [Démarrage et arrêt de la réplication avec des réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.StartStop.md)
+ [Résolution d'un problème de réplica en lecture MySQL](USER_ReadRepl.Troubleshooting.md)
## Configuration des réplicas en lecture avec MySQL
Avant qu'une instance de base de données MySQL puisse être utilisée comme source de réplication, vous devez activer les sauvegardes automatiques sur l'instance de base de données source. Pour cela, vous devez définir la période de rétention des sauvegardes sur une valeur autre que 0. Cette exigence s'applique également à un réplica en lecture qui serait l'instance de base de données source d'un autre réplica en lecture. Les sauvegardes automatiques sont prises en charge pour les réplicas en lecture exécutant n'importe quelle version de MySQL. Vous pouvez configurer la réplication en fonction des coordonnées des journaux binaires pour une instance de base de données MySQL.
Vous pouvez configurer la réplication à l’aide des identifiants de transaction globaux (GTIDS) sur les versions suivantes :
+ RDS for MySQL version 5.7.44 et versions 5.7 ultérieures
+ RDS for MySQL version 8.0.28 et versions 8.0 ultérieures
+ RDS for MySQL version 8.4.3 et versions 8.4 ultérieures
Pour de plus amples informations, veuillez consulter [Utilisation de la réplication basée sur des identifiants de transaction globaux (GTID)](mysql-replication-gtid.md).
Vous pouvez créer jusqu'à 15 réplicas en lecture à partir d'une seule instance de base de données au sein de la même région. 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 l'instance de base de données source. Si vous mettez à l'échelle l'instance de base de données source, faites-le également pour les réplicas en lecture.
RDS for MySQL prend en charge les réplicas en lecture en cascade. Pour apprendre à configurer des réplicas en lecture en cascade, consultez [Utilisation de réplicas en lecture en cascade avec RDS for MySQL](USER_MySQL.Replication.ReadReplicas.Cascading.md).
Vous pouvez exécuter simultanément plusieurs actions de création et suppression de réplicas en lecture qui référencent la même instance de base de données source. Lorsque vous effectuez ces actions, restez dans la limite de 15 réplicas en lecture pour chaque instance source.
Un réplica en lecture d'une instance de base de données MySQL ne peut pas utiliser une version de moteur de base de données inférieure à son instance de base de données source.
### Préparation des instances de base de données MySQL qui utilisent MyISAM
Si votre instance de base de données MySQL utilise un moteur non transactionnel tel que MyISAM, vous devez effectuer les étapes suivantes pour configurer correctement votre réplica en lecture. Ces étapes sont nécessaires pour vous assurer que le réplica en lecture dispose d'une copie cohérente de vos données. Ces étapes ne sont pas nécessaires si toutes vos tables utilisent un moteur transactionnel comme InnoDB.
1. Arrêtez toutes les opérations DML (Data Manipulation Language) et DDL (Data Definition Language) sur les tables non transactionnelles dans l'instance de bases de données source et attendez qu'elles se terminent. Les instructions SELECT peuvent continuer à fonctionner.
1. Videz et verrouillez les tables dans l'instance de bases de données source.
1. Créez le réplica en lecture en suivant l'une des méthodes présentées dans les sections suivantes.
1. Vérifiez l'avancement de la création du réplica en lecture en utilisant, par exemple, l'opération d'API `DescribeDBInstances`. Une fois que le réplica en lecture est disponible, déverrouillez les tables de l'instance de base de données source et reprenez les opérations de base de données normales.
# Configuration des filtres de réplication avec 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 une instance de base de données qui a lu des répliques dans différentes bases de données Régions AWS, pour répliquer différentes bases de données ou tables dans différentes. Régions AWS
**Note**
Vous pouvez également utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec une instance de base de données MySQL principale configurée en tant que réplica dans une topologie de réplication entrante. Pour en savoir plus sur cette configuration, consultez [Configuration d’une réplication de position de fichier journal binaire avec une instance source externe](MySQL.Procedural.Importing.External.Repl.md).
**Topics**
+ [
## Définition des paramètres de filtrage de la réplication pour RDS for MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Configuring)
+ [
## Limites du filtrage de réplication pour RDS for MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Limitations)
+ [
## Exemples de filtrage de réplication pour RDS for MySQL
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Examples)
+ [
## Affichage des filtres de réplication pour un réplica en lecture
](#USER_MySQL.Replication.ReadReplicas.ReplicationFilters.Viewing)
## Définition des paramètres de filtrage de la réplication pour RDS for MySQL
Pour configurer des filtres de réplication, définissez les paramètres de filtrage de réplication suivants sur le réplica en lecture :
+ `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 réplica en lecture, 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 réplica en lecture, 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 réplica en lecture.
+ `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 réplica en lecture, 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 réplica en lecture.
+ `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 réplica en lecture, 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 réplica en lecture, 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' RDS pour la journalisation binaire MySQL pour 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 RDS for MySQL
Les limites suivantes s'appliquent au filtrage de réplication pour RDS for MySQL :
+ 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 pour les valeurs de paramètres. Dans une liste de paramètres, les virgules ne peuvent être utilisées que comme séparateurs de valeurs. Par exemple, `ParameterValue='`a,b`'` est pris en charge, mais `ParameterValue='a,b'` ne l’est pas.
+ Les options `--binlog-do-db` et `--binlog-ignore-db` de MySQL pour le filtrage des journaux binaires ne sont pas prises en charge.
+ Le filtrage de réplication ne prend pas en charge les transactions XA.
Pour plus d'informations, consultez la section [Restrictions on XA Transactions (Restrictions sur les transactions XA)](https://dev.mysql.com/doc/refman/8.0/en/xa-restrictions.html) dans la documentation MySQL.
## Exemples de filtrage de réplication pour RDS for 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 associé au réplica en lecture.
**Note**
Vous ne pouvez pas modifier un groupe de paramètres 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 base de données, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
Vous pouvez définir les paramètres d'un groupe de paramètres à l'aide de l'API AWS Management Console AWS CLI, ou 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 RDS](USER_WorkingWithParamGroups.Modifying.md). Lorsque vous définissez des paramètres dans un groupe de paramètres, toutes les instances de base de données associées 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, assurez-vous que le groupe de paramètres est associé uniquement aux 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-mysql)
+ [Including tables in replication](#rep-filter-in-tables-mysql)
+ [Including tables in replication with wildcard characters](#rep-filter-in-tables-wildcards-mysql)
+ [Excluding databases from replication](#rep-filter-ex-dbs-mysql)
+ [Excluding tables from replication](#rep-filter-ex-tables-mysql)
+ [Excluding tables from replication using wildcard characters](#rep-filter-ex-tables-wildcards-mysql)
**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-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-db,ParameterValue='mydb1,mydb2',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-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-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-table,ParameterValue='mydb1.table1,mydb1.table2',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-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-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-wild-do-table,ParameterValue='mydb.order%,mydb.return%',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-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-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-db,ParameterValue='mydb5,mydb6',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-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-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-table,ParameterValue='mydb5.table1,mydb6.table2',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-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-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-wild-ignore-table,ParameterValue='mydb7.order%,mydb7.return%',ApplyMethod=immediate"
```
Pour Windows :
```
aws rds modify-db-parameter-group ^
--db-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 RDS](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 :
+ `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.
# Configuration de la réplication retardée avec MySQL
Vous pouvez utiliser la réplication retardée comme stratégie pour la reprise après sinistre. Avec la réplication retardée, vous spécifiez la durée minimale, en secondes, pour retarder la réplication de la source vers la réplique de lecture. En cas de sinistre, par exemple la suppression accidentelle d'une table, vous appliquez la procédure suivante pour reprendre rapidement après le sinistre :
+ Arrêtez la réplication vers le réplica en lecture avant que lui soit envoyée la modification qui a provoqué le sinistre.
Utilisez la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) pour arrêter la réplication.
+ Arrêtez la réplication et précisez qu'elle doit s'arrêter automatiquement à une position donnée dans un fichier journal.
Vous indiquez une position juste avant le sinistre grâce à la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until).
+ Effectuez la promotion du réplica en lecture pour qu'il devienne la nouvelle instance de base de données source, en suivant les instructions figurant dans [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
**Note**
Sur RDS for MySQL 8.4, la réplication retardée est prise en charge pour MySQL 8.4.3 et versions ultérieures. Sur RDS for MySQL 8.0, la réplication retardée est prise en charge pour MySQL 8.0.28 et versions ultérieures. Sur RDS for MySQL 5.7, la réplication retardée est prise en charge pour MySQL 5.7.44 et versions ultérieures.
Utilisez des procédures stockées pour configurer la réplication retardée. Vous ne pouvez pas configurer la réplication différée avec AWS Management Console AWS CLI, l'API ou l'API Amazon RDS.
Vous pouvez utiliser la réplication basée sur les identificateurs de transaction globaux (GTIDs) dans une configuration de réplication différée pour les versions suivantes :
RDS for MySQL version 5.7.44 et versions 5.7 ultérieures
RDS for MySQL version 8.0.28 et versions 8.0 ultérieures
RDS for MySQL version 8.4.3 et versions 8.4 ultérieures
Si vous utilisez une réplication basée sur des identifiants de transaction globaux (GTID), utilisez la procédure stockée [](mysql-stored-proc-gtid.md#mysql_rds_start_replication_until_gtid) au lieu de la procédure stockée [](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).
**Topics**
+ [
## Configuration de la réplication retardée pendant la création du réplica en lecture
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ReplicaCreation)
+ [
## Modification de la réplication retardée pour un réplica en lecture existant
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.ExistingReplica)
+ [
## Définition d'une position où arrêter la réplication vers un réplica en lecture
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.StartUntil)
+ [
## Promotion d’un réplica en lecture
](#USER_MySQL.Replication.ReadReplicas.DelayReplication.Promote)
## Configuration de la réplication retardée pendant la création du réplica en lecture
Pour configurer la réplication retardée pour tout réplica en lecture à venir créé à partir d'une instance de base de données, exécutez la procédure stockée [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) avec le paramètre `target delay`.
**Pour configurer la réplication retardée pendant la création du réplica en lecture**
1. À l'aide d'un client MySQL, connectez-vous à l'instance de base de données MySQL qui constituera la source des réplicas en lecture en tant qu'utilisateur principal.
1. Exécutez la procédure stockée [mysql.rds\$1set\$1configuration](mysql-stored-proc-configuring.md#mysql_rds_set_configuration) avec le paramètre `target delay`.
Par exemple, exécutez la procédure stockée suivante pour indiquer que la réplication est retardée d'au moins une heure (3 600 secondes) pour tout réplica en lecture créé à partir de l'instance de base de données actuelle.
```
call mysql.rds_set_configuration('target delay', 3600);
```
**Note**
Après avoir exécuté cette procédure stockée, toute réplique de lecture que vous créez à l' AWS CLI aide de l'API Amazon RDS est configurée avec un délai de réplication du nombre de secondes spécifié.
## Modification de la réplication retardée pour un réplica en lecture existant
Pour modifier la réplication retardée pour un réplica en lecture existant, exécutez la procédure stockée [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay).
**Pour modifier la réplication retardée pour un réplica en lecture existant**
1. En utilisant un client MySQL, connectez-vous au réplica en lecture en tant qu'utilisateur principal.
1. Utilisez la procédure stockée [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) pour arrêter la réplication.
1. Exécutez la procédure stockée [mysql.rds\$1set\$1source\$1delay](mysql-stored-proc-replicating.md#mysql_rds_set_source_delay).
Par exemple, exécutez la procédure stockée suivante pour indiquer que la réplication vers le réplica en lecture est retardée d'au moins une heure (3 600 secondes).
```
call mysql.rds_set_source_delay(3600);
```
1. Utilisez la procédure stockée [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour lancer la réplication.
## Définition d'une position où arrêter la réplication vers un réplica en lecture
Après avoir arrêté la réplication vers le réplica en lecture, 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-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. En utilisant un client MySQL, connectez-vous à l'instance de base de données MySQL source en tant qu'utilisateur principal.
1. Exécutez la procédure stockée [](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`.
## Promotion d’un réplica en lecture
Après l'arrêt de la réplication, dans un scénario de reprise après sinistre, vous pouvez promouvoir un réplica en lecture comme nouvelle instance de base de données source. Pour de plus amples informations sur la promotion d'un réplica en lecture, veuillez consulter [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
# Mise à jour des réplicas en lecture avec MySQL
Les réplicas en lecture sont conçus pour prendre en charge les requêtes de lecture, mais vous pouvez avoir besoin de mises à jour ponctuelles. À titre d'exemple, vous pouvez avoir besoin d'ajouter un index, pour optimiser les types spécifiques de requêtes qui accèdent au réplica.
Bien que vous puissiez activer les mises à jour en définissant le paramètre `read_only` sur `0` dans le groupe de paramètres de base de données pour le réplica en lecture, nous vous recommandons de ne pas le faire car cela peut poser des problèmes si le réplica en lecture devient incompatible avec l'instance de base de données source. Pour les opérations de maintenance, nous vous recommandons d'utiliser blue/green des déploiements. Pour de plus amples informations, veuillez consulter [Utilisation des Blue/Green déploiements pour les mises à jour de bases de](blue-green-deployments.md).
Si vous désactivez la lecture seule sur un réplica en lecture, modifiez la valeur du paramètre `1` pour rétablir `read_only` dès que possible.
# Utiliser des déploiements de réplicas en lecture Multi-AZ avec MySQL
Vous pouvez créer un réplica en lecture à partir de déploiements d'instance de base de données mono-AZ ou multi-AZ. Vous utilisez des déploiements multi-AZ pour améliorer la durabilité et la disponibilité des données critiques, mais vous ne pouvez pas utiliser une instance secondaire multi-AZ pour servir les requêtes en lecture seule. À la place, vous pouvez créer des réplicas en lecture à partir d'instances de base de données multi-AZ à trafic élevé pour décharger les requêtes en lecture seule. Si l'instance source d'un déploiement multi-AZ bascule vers l'instance secondaire, tous les réplicas en lecture associés se mettent automatiquement à utiliser l'instance secondaire (désormais principale) comme source de réplication. Pour plus d'informations, consultez [Configuration et gestion d’un déploiement multi-AZ pour Amazon RDS](Concepts.MultiAZ.md).
Vous pouvez créer un réplica en lecture en tant qu'instance de base de données Multi-AZ. Amazon RDS crée une instance de secours de votre réplica dans une autre zone de disponibilité pour la prise en charge du basculement pour le réplica. La création de votre réplica en lecture en tant qu'instance de base de données multi-AZ est indépendante du fait que la base de données source soit ou non une instance de base de données multi-AZ.
# Utilisation de réplicas en lecture en cascade avec RDS for MySQL
RDS for MySQL prend en charge les réplicas en lecture en cascade. Les *réplicas en lecture en cascade* vous permettent de mettre à l'échelle les lectures sans surcharger votre instance de base de données RDS for MySQL source.
Avec les réplicas en lecture en cascade, votre instance de base de données RDS for MySQL envoie des données au premier réplica en lecture de la chaîne. Ce réplica en lecture envoie ensuite les données au deuxième réplica de la chaîne, etc. Au final, tous les réplicas en lecture de la chaîne ont reçu les modifications de l'instance de base de données RDS for MySQL, sans surcharger uniquement l'instance de base de données source.
Vous pouvez créer une série comportant jusqu'à trois réplicas en lecture dans une chaîne à partir d'une instance de base de données RDS for MySQL source. Par exemple, supposons que vous disposez d'une instance de base de données RDS for MySQL, `mysql-main`. Vous pouvez effectuer les actions suivantes :
+ À partir de `mysql-main`, créez le premier réplica en lecture de la chaîne, `read-replica-1`.
+ Ensuite, à partir de `read-replica-1`, créez le réplica en lecture suivant dans la chaîne, `read-replica-2`.
+ Enfin, à partir de `read-replica-2`, créez le troisième réplica en lecture de la chaîne, `read-replica-3`.
Vous ne pouvez pas créer un autre réplica en lecture au-delà de ce troisième réplica en lecture en cascade dans la série pour `mysql-main`. Une série complète d'instances allant d'une instance de base de données source RDS for MySQL jusqu'à la fin d'une série de réplicas en lecture en cascade peut comporter au plus quatre instances de base de données.
Pour que les réplicas en lecture en cascade fonctionnent, les sauvegardes automatisées doivent être activées sur chaque instance de base de données RDS for MySQL. Pour activer les sauvegardes automatiques sur un réplica en lecture, commencez par créer le réplica en lecture, puis modifiez-le pour activer les sauvegardes automatiques. Pour plus d’informations, consultez [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Comme pour tout réplica en lecture, vous pouvez promouvoir un réplica en lecture faisant partie d’une cascade. La promotion d’un réplica en lecture depuis une chaîne de réplicas en lecture retire ce réplica de la chaîne. Par exemple, supposons que vous souhaitez déplacer une partie de la charge de travail de votre instance de base de données `mysql-main` vers une nouvelle instance destinée uniquement au service comptable. En prenant pour hypothèse la chaîne de trois réplicas en lecture de l’exemple, vous décidez de promouvoir `read-replica-2`. La chaîne est affectée comme suit :
+ La promotion de `read-replica-2` le retire de la chaîne de réplication.
+ Il s’agit désormais d’une instance de base de données en lecture/écriture complète.
+ La réplication continue sur `read-replica-3`, tout comme avant la promotion.
+ Votre `mysql-main` continue la réplication sur `read-replica-1`.
Pour plus d’informations sur la promotion des réplicas en lecture, consultez [Promotion d'un réplica en lecture en instance de bases de données autonome](USER_ReadRepl.Promote.md).
# Surveillance du retard de réplication pour les réplicas en lecture MySQL
Pour les réplicas en lecture MySQL, vous pouvez surveiller le retard de réplication dans Amazon CloudWatch en consultant la métrique Amazon RDS `ReplicaLag`. La métrique `ReplicaLag` contient la valeur du champ `Seconds_Behind_Master` de la commande `SHOW REPLICA STATUS`.
Les causes courantes du retard de réplication pour MySQL sont les suivantes :
+ Une indisponibilité du réseau.
+ L'écriture dans des tables avec des index différents sur un réplica en lecture. Si le paramètre `read_only` est défini sur `0` sur le réplica en lecture, la réplication peut être rompue si le réplica en lecture devient incompatible avec l'instance de base de données source. Une fois que vous avez effectué les tâches de maintenance sur le réplica en lecture, nous vous recommandons de définir à nouveau le paramètre `read_only` sur `1`.
+ Utilisation d’un moteur de stockage non transactionnel tel que MyISAM. La réplication est uniquement prise en charge pour le moteur de stockage InnoDB sur MySQL.
Lorsque la métrique `ReplicaLag` atteint 0, le réplica a rattrapé le retard sur l’instance de base de données source. Si la métrique `ReplicaLag` retourne -1, la réplication n’est actuellement pas active. `ReplicaLag`= -1 est équivalent à `Seconds_Behind_Master` = `NULL`.
# Démarrage et arrêt de la réplication avec des réplicas en lecture MySQL
Vous pouvez arrêter et redémarrer le processus de réplication sur une instance de base de données Amazon RDS en appelant les procédures stockées système [mysql.rds\$1stop\$1replication](mysql-stored-proc-replicating.md#mysql_rds_stop_replication) et [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication). Vous pouvez procéder ainsi lors d'une réplication entre deux instances Amazon RDS pour des opérations de longue durée, telles que la création d'un grand index. Vous devez également arrêter et démarrer la réplication lors de l'importation ou de l'exportation de bases de données. Pour plus d’informations, consultez [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md) et [Exportation de données à partir d'une instance DB MySQL grâce à la réplication](MySQL.Procedural.Exporting.NonRDSRepl.md).
Si la réplication est arrêtée pendant plus de 30 jours consécutifs, manuellement ou en raison d'une erreur de réplication, Amazon RDS met fin à la réplication entre l'instance de base de données source et tous les réplicas en lecture. Cela permet d'éviter l'augmentation des besoins en stockage sur l'instance de bases de données source et d'importants délais de basculement. L'instance de base de données du réplica en lecture est toujours disponible. En revanche, la réplication ne peut pas être reprise, car les journaux binaires requis par le réplica en lecture sont supprimés de l'instance de base de données source une fois la réplication terminée. Vous pouvez créer un nouveau réplica en lecture pour l'instance de base de données source afin de rétablir la réplication.
# Résolution d'un problème de réplica en lecture MySQL
Dans certains cas, pour les instances de base de données, les réplicas en lecture présentent des erreurs ou des incohérences de données (ou les deux) entre le réplica en lecture et son instance de base de données source. Ce problème survient quand des événements de journaux binaires ou des journaux redo InnoDB ne sont pas vidés lors d'une panne du réplica en lecture ou de l'instance de base de données source. Dans ces situations, supprimez et recréez manuellement les réplicas en lecture. Vous pouvez réduire la probabilité que cela se produise en définissant les valeurs de paramètre suivantes : `sync_binlog=1` et `innodb_flush_log_at_trx_commit=1`. Ces paramètres peuvent réduire les performances. Testez donc leur impact avant d’implémenter les modifications dans un environnement de production.
**Avertissement**
Dans le groupe de paramètres associé à l'instance de base de données source, nous recommandons de conserver ces valeurs de paramètres : `sync_binlog=1` et `innodb_flush_log_at_trx_commit=1`. Ces paramètres sont dynamiques. Si vous ne souhaitez pas utiliser ces paramètres, nous vous recommandons de définir temporairement ces valeurs avant d'exécuter toute opération sur l'instance de base de données source susceptible de provoquer son redémarrage. Ces opérations incluent, sans s'y limiter, le redémarrage, le redémarrage avec basculement, la mise à niveau de la version de la base de données et la modification de la classe d'instance de base de données ou de son stockage. La même recommandation s'applique à la création de nouveaux réplicas en lecture pour l'instance de base de données source.
Le non-respect de ces instructions augmente le risque que les réplicas en lecture présentent des erreurs ou des incohérences de données (ou les deux) entre le réplica en lecture et son instance de base de données source.
Les technologies de réplication pour MySQL sont asynchrones. Parce qu’elles sont asynchrones, des augmentations occasionnelles de `BinLogDiskUsage` sur l’instance de base de données source et `ReplicaLag` sur le réplica en lecture sont prévisibles. Par exemple, un volume élevé d’opérations d’écriture sur l’instance de bases de données source peut se produire en parallèle. Tandis que les opérations d’écritures sur le réplica en lecture sont sérialisées à l’aide d’un seul thread d’I/O, ce qui peut conduire à un retard entre l’instance source et le réplica. Pour plus d’informations sur les réplicas en lecture seule dans la documentation MySQL, consultez [Détails d’implémentation de la réplication](https://dev.mysql.com/doc/refman/8.0/en/replication-implementation-details.html).
Vous pouvez effectuer plusieurs opérations pour réduire le retard entre les mises à jour d’une instance de base de données source et les mises à jour suivantes appliquées au réplica en lecture, telles que les opérations suivantes :
+ Dimensionnement d’un réplica en lecture pour qu’il ait une taille de stockage et une classe d’instance de base de données comparables à celles de l’instance de base de données source.
+ Garantie que les réglages des paramètres dans les groupes de paramètres de base de données utilisés par l’instance de base de données source et le réplica en lecture sont compatibles. Pour obtenir plus d’informations et un exemple, reportez-vous à la présentation du paramètre `max_allowed_packet`, plus loin dans cette section.
Amazon RDS surveille l’état de réplication de vos réplicas en lecture et met à jour le champ `Replication State` de l’instance du réplica en lecture avec la valeur `Error` si la réplication s’arrête pour une raison quelconque. Par exemple, dans le cas de requêtes DML exécutées sur votre réplica en lecture qui sont en conflit avec les mises à jour effectuées sur l’instance de base de données source.
Vous pouvez passer en revue les détails de l'erreur associée et déclenchée par le moteur MySQL, en consultant le champ `Replication Error`. Des événements indiquant l’état du réplica en lecture sont également générés, y compris [RDS-EVENT-0045](USER_Events.Messages.md#RDS-EVENT-0045), [RDS-EVENT-0046](USER_Events.Messages.md#RDS-EVENT-0046) et [RDS-EVENT-0047](USER_Events.Messages.md#RDS-EVENT-0047). Pour plus d’informations sur les événements et l’abonnement aux événements, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md). Si un message d'erreur MySQL est renvoyé, passez en revue le numéro de l'erreur dans la [documentation sur les messages d'erreur MySQL](https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html).
Un problème courant susceptible de causer des erreurs de réplication se pose lorsque la valeur du paramètre `max_allowed_packet` d’un réplica en lecture est inférieure à celle du paramètre `max_allowed_packet` de l’instance de base de données source. Le paramètre `max_allowed_packet` est un paramètre personnalisé que vous pouvez définir dans un groupe de paramètres de base de données. Vous utilisez `max_allowed_packet` pour spécifier la taille maximale du code DML qui peut être exécuté sur la base de données. Dans certains cas, la valeur `max_allowed_packet` du groupe de paramètres de base de données associé à un réplica en lecture est inférieure à la valeur `max_allowed_packet` du groupe de paramètres de base de données associé à l'instance de base de données source. Dans ces cas, le processus de réplication peut lancer l'erreur `Packet bigger than 'max_allowed_packet' bytes` et arrêter la réplication. Pour corriger cette erreur, faites en sorte que l'instance de base de données source et le réplica en lecture utilisent des groupes de paramètres de base de données avec les mêmes valeurs pour le paramètre `max_allowed_packet`.
Voici d’autres situations courantes susceptibles de causer des erreurs de réplication :
+ Écriture sur les tables d’un réplica en lecture. Dans certains cas, vous pouvez créer des index sur un réplica en lecture différents des index sur l'instance de base de données source. Vous devez alors définir le paramètre `read_only` sur `0` pour créer les index. Si vous écrivez dans des tables sur le réplica en lecture, cela peut interrompre la réplication si le réplica en lecture devient incompatible avec l'instance de base de données source. Une fois que vous avez effectué les tâches de maintenance sur le réplica en lecture, nous vous recommandons de définir à nouveau le paramètre `read_only` sur `1`.
+ Utilisation d'un moteur de stockage non transactionnel tel que MyISAM. Les réplicas en lecture nécessitent un moteur de stockage transactionnel. La réplication est uniquement prise en charge pour le moteur de stockage InnoDB sur MySQL.
+ Utilisation de requêtes non déterministes non sécurisées telles que `SYSDATE()`. Pour plus d’informations, consultez [Determination of safe and unsafe statements in binary logging](https://dev.mysql.com/doc/refman/8.0/en/replication-rbr-safe-unsafe.html).
Si vous décidez que vous pouvez ignorer une erreur en toute sécurité, vous pouvez suivre la procédure décrite dans la section [Ignorer une erreur de réplication pour RDS for MySQL](Appendix.MySQL.CommonDBATasks.SkipError.md). Sinon, vous pouvez d'abord supprimer le réplica en lecture. Vous créez ensuite une instance à l'aide du même identifiant d'instance de base de données, de telle sorte que le point de terminaison demeure le même que celui de votre ancien réplica en lecture. Si une erreur de réplication est corrigée, le champ `Replication State` prend la valeur *replicating (réplication en cours)*.
# 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 les instances de base de données Amazon RDS for MySQL.
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 basée sur GTID est prise en charge pour les versions suivantes :
+ Toutes les versions RDS for MySQL 8.4
+ Toutes les versions RDS for MySQL 8.0
+ Toutes les versions RDS for MySQL 5.7
Toutes les instances de base de données MySQL dans une configuration de réplication doivent respecter cette exigence de version.
**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 sur les nouveaux réplicas en lecture dans RDS for MySQL
](mysql-replication-gtid.configuring-new-read-replicas.md)
+ [
# Activation de la réplication GTID sur les réplicas en lecture existants dans RDS for MySQL
](mysql-replication-gtid.configuring-existing-read-replicas.md)
+ [
# Désactivation de la réplication GTID pour une instance de base de données MySQL avec des réplicas en lecture
](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.
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.
Vous pouvez utiliser la réplication basée sur GTID pour répliquer des données avec des réplicas en lecture RDS for MySQL. Vous pouvez configurer une réplication GTID lorsque vous créez de nouveaux réplicas en lecture, ou convertir des réplicas en lecture existants pour utiliser la réplication GTID.
Vous pouvez également utiliser la réplication GTID dans une configuration de réplication retardée avec RDS for MySQL. Pour plus d’informations, consultez [Configuration de la réplication retardée avec MySQL](USER_MySQL.Replication.ReadReplicas.DelayReplication.md).
## 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 instance de base de données ou de votre réplica en lecture :
+ `ON` et `ON_PERMISSIVE` s'appliquent uniquement à la réplication sortante à partir d'une instance de base de données RDS. Ces deux valeurs font que votre instance de base de données RDS utilise les GTID pour les transactions qui sont répliquées. `ON` exige que la base de données cible utilise également la réplication basée sur les GTID. `ON_PERMISSIVE` rend la réplication basée sur les GTID facultative sur la base de données cible.
+ S'il est défini, `OFF_PERMISSIVE` indique que vos instances de base de données RDS peuvent accepter la réplication entrante d'une base de données source. Elles peuvent le faire indépendamment du fait que la base de données source utilise ou non la réplication basée sur les GTID.
+ S'il est défini, `OFF` indique que votre instance de base de données RDS n'accepte que la réplication entrante des bases de données sources qui n'utilisent pas la réplication basée sur les GTID.
Pour plus d’informations sur les groupes de paramètres, consultez [Groupes de paramètres pour Amazon RDS](USER_WorkingWithParamGroups.md).
# Activation de la réplication GTID sur les nouveaux réplicas en lecture dans RDS for MySQL
Lorsque la réplication GTID est activée pour une instance de base de données RDS for MySQL, elle est configurée automatiquement pour les réplicas en lecture de l’instance de base de données.
**Pour activer la réplication GTID pour des nouveaux réplicas en lecture**
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données contient la configuration de paramètres suivante :
+ `gtid_mode` : `ON` ou `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
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 RDS](USER_WorkingWithParamGroups.md).
1. Si vous avez modifié le groupe de paramètres de l’instance de base de données, redémarrez celle-ci. Pour en savoir plus à ce sujet, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
1. Créez un ou plusieurs réplicas en lecture de l’instance de base de données. Pour en savoir plus à ce sujet, consultez [Création d’un réplica en lecture](USER_ReadRepl.Create.md).
Amazon RDS tente d’établir une réplication GTID entre l’instance de base de données MySQL et les réplicas en lecture à l’aide du paramètre `MASTER_AUTO_POSITION`. En cas d’échec, Amazon RDS utilise les positions de fichiers journaux pour la réplication avec les réplicas en lecture. Pour plus d’informations sur le paramètre `MASTER_AUTO_POSITION`, consultez la page [GTID Auto-Positioning](https://dev.mysql.com/doc/refman/5.7/en/replication-gtids-auto-positioning.html) dans la documentation MySQL.
# Activation de la réplication GTID sur les réplicas en lecture existants dans RDS for MySQL
Pour une instance de base de données MySQL existante avec des réplicas en lecture qui n’utilise pas la réplication GTID, vous pouvez configurer la réplication GTID entre l’instance de base de données et les réplicas en lecture.
**Pour activer la réplication GTID pour des réplicas en lecture existants**
1. Si l’instance de base de données ou un réplica en lecture utilise une version 8.0 de RDS for MySQL inférieure à la version 8.0.26, mettez à niveau l’instance de base de données ou le réplica en lecture vers la version 8.0.26 ou une version supérieure de MySQL 8.0. Toutes les versions de RDS for MySQL 8.4 et 5.7 prennent en charge la réplication GTID.
Pour plus d’informations, consultez [Mises à niveau du moteur de base de données RDS for MySQL](USER_UpgradeDBInstance.MySQL.md).
1. (Facultatif) Réinitialisez les paramètres GTID et testez le comportement de l’instance de base de données et des réplicas en lecture :
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données et à chaque réplica en lecture contient le paramètre `enforce_gtid_consistency` défini sur `WARN`.
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 RDS](USER_WorkingWithParamGroups.md).
1. Si vous avez modifié le groupe de paramètres de l’instance de base de données, redémarrez celle-ci. Si vous modifiez le groupe de paramètres pour un réplica en lecture, redémarrez celui-ci.
Pour plus d’informations, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
1. Exécutez votre instance de base de données et vos réplicas en lecture avec votre charge de travail normale et surveillez les fichiers journaux.
Si vous recevez des avertissements relatifs à des transactions incompatibles avec les identifiants de transaction globaux, modifiez votre application de sorte qu’elle utilise uniquement des fonctions compatibles avec les identifiants de transaction globaux. Assurez-vous que l’instance de base de données ne génère aucun avertissement relatif à des transactions incompatibles avec les identifiants de transaction globaux avant de passer à l’étape suivante.
1. Réinitialisez les paramètres GTID de la réplication basée sur des identifiants de transaction globaux qui autorise les transactions anonymes jusqu’à ce que les réplicas en lecture les aient toutes traitées.
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données et à chaque réplica en lecture contient la configuration de paramètres suivante :
+ `gtid_mode` – `ON_PERMISSIVE`
+ `enforce_gtid_consistency` – `ON`
1. Si vous avez modifié le groupe de paramètres de l’instance de base de données, redémarrez celle-ci. Si vous modifiez le groupe de paramètres pour un réplica en lecture, redémarrez celui-ci.
1. Attendez que toutes vos transactions anonymes soient répliquées. Pour vérifier qu’elles ont été répliquées, procédez comme suit :
1. Exécutez l’instruction suivante sur votre instance de base de données source.
**MySQL 8.4**
```
SHOW BINARY LOG STATUS;
```
**MySQL 5.7 et 8.0**
```
SHOW MASTER STATUS;
```
Notez les valeurs dans les colonnes `File` et `Position`.
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.
```
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.
```
SELECT MASTER_POS_WAIT('mysql-bin-changelog.000031', 107);
```
Si le réplica en lecture a dépassé la position spécifiée, la requête renvoie immédiatement un résultat. Sinon, la fonction attend. Passez à l’étape suivante lorsque la requête a renvoyé un résultat pour tous les réplicas en lecture.
1. Réinitialisez les paramètres GTID uniquement pour la réplication GTID.
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données et à chaque réplica en lecture contient la configuration de paramètres suivante :
+ `gtid_mode` – `ON`
+ `enforce_gtid_consistency` – `ON`
1. Redémarrez l’instance de base de données et chaque réplica en lecture.
1. Sur chaque réplica en lecture, exécutez la procédure suivante.
**Versions majeures MySQL 8.4 et ultérieures**
```
CALL mysql.rds_set_source_auto_position(1);
```
**Versions majeures MySQL 8.0 et antérieures**
```
CALL mysql.rds_set_master_auto_position(1);
```
# Désactivation de la réplication GTID pour une instance de base de données MySQL avec des réplicas en lecture
Vous pouvez désactiver la réplication GTID pour un une instance de base de données MySQL avec des réplicas en lecture.
**Pour désactiver la réplication GTID pour une instance de base de données MySQL avec des réplicas en lecture**
1. Sur chaque réplica en lecture, exécutez la procédure suivante :
**Versions majeures MySQL 8.4 et ultérieures**
```
CALL mysql.rds_set_source_auto_position(0);
```
**Versions majeures MySQL 8.0 et antérieures**
```
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 associé à l’instance de base de données MySQL et à chaque réplica en lecture 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 RDS](USER_WorkingWithParamGroups.md).
1. Relancez l’instance de base de données MySQL et chaque réplica en lecture. Pour plus d’informations sur le redémarrage, consultez [Redémarrage d'une instance de base de données cluster de base de données](USER_RebootInstance.md).
1. Réinitialisez `gtid_mode` sur `OFF_PERMISSIVE`.
1. Assurez-vous que le groupe de paramètres associé à l’instance de base de données MySQL et à chaque réplica en lecture contient le paramètre `gtid_mode` défini sur `OFF_PERMISSIVE`.
1. Relancez l’instance de base de données MySQL et chaque réplica en lecture.
1. Attendez que toutes les transactions GTID soient appliquées sur tous les réplicas en lecture. Pour vérifier qu’elles ont été appliquées, procédez comme suit :
1. Exécutez la commande suivante sur l’instance de base de données MySQL :
**MySQL 8.4**
```
SHOW BINARY LOG STATUS
```
**MySQL 5.7 et 8.0**
```
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 :
**MySQL 8.4, ainsi que MySQL 8.0.26 et les versions ultérieures de MySQL**
```
SELECT SOURCE_POS_WAIT('file', position);
```
**MySQL 5.7**
```
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 :
**MySQL 8.4, ainsi que MySQL 8.0.26 et les versions ultérieures de MySQL**
```
SELECT SOURCE_POS_WAIT('mysql-bin-changelog.000031', 107);
```
**MySQL 5.7**
```
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 associé à l’instance de base de données MySQL et à chaque réplica en lecture contient la configuration de paramètres suivante :
+ `gtid_mode` – `OFF`
+ `enforce_gtid_consistency` – `OFF`
1. Relancez l’instance de base de données MySQL et chaque réplica en lecture.
# Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
Vous pouvez configurer la réplication entre une instance de base de données RDS for MySQL ou MariaDB et une instance MySQL ou MariaDB externe à Amazon RDS en utilisant la réplication de fichiers journaux binaires.
**Topics**
+ [
## Avant de commencer
](#MySQL.Procedural.Importing.External.Repl.BeforeYouBegin)
+ [
## Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
](#MySQL.Procedural.Importing.External.Repl.Procedure)
## Avant de commencer
Vous pouvez configurer la réplication en utilisant la position du fichier journal binaire des transactions répliquées.
Les autorisations requises pour démarrer la réplication sur une instance de base de données Amazon RDS sont restreintes et ne sont pas disponibles pour votre utilisateur principal Amazon RDS. Pour cette raison, assurez-vous d’utiliser les commandes Amazon RDS [mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master) ou [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](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 base de données active et votre base de données Amazon RDS.
Pour définir le format de journalisation binaire pour une base de données MySQL ou MariaDB, mettez à jour le paramètre `binlog_format`. Si votre instance de base de données utilise le groupe de paramètres d’instance de base de données par défaut, créez un nouveau groupe de paramètres de base de données pour modifier le paramètre `binlog_format`. Dans MariaDB, MySQL 8.0 et versions antérieures, la valeur par défaut de `binlog_format` est `MIXED`. Cependant, vous pouvez également définir `binlog_format` sur `ROW` ou `STATEMENT` si vous avez besoin d’un format de journaux binaires (binlog) spécifique. Redémarrez votre instance de base de données pour que les modifications prennent effet. Dans MySQL 8.4 et versions ultérieures, la valeur par défaut de `binlog_format` est `ROW`.
Pour plus d’informations sur la configuration du paramètre `binlog_format`, consultez [Configuration d' RDS pour la journalisation binaire MySQL pour les bases de données mono-AZ](USER_LogAccess.MySQL.BinaryFormat.md). Pour plus d’informations sur les implications des différents types de réplication MySQL, consultez [Advantages and Disadvantages of Statement-Based and Row-Based Replication](https://dev.mysql.com/doc/refman/8.0/en/replication-sbr-rbr.html) de la documentation MySQL.
## Configuration d’une réplication de position de fichier journal binaire avec une instance source externe
Suivez ces instructions lorsque vous configurez une instance source externe et un réplica sur Amazon RDS :
+ Surveillez les événements de basculement de l'instance de base de données Amazon RDS qui constitue votre réplica. En cas de basculement, l'instance de base de données qui est votre réplica peut alors être recréée sur un nouvel hôte avec une autre adresse réseau. 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).
+ Tenez à jour les journaux binaires sur votre instance source jusqu’à ce que vous ayez vérifié qu’ils ont été appliqués au réplica. Cette maintenance garantit que vous pouvez restaurer votre instance source en cas de défaillance.
+ Activez les sauvegardes automatiques sur votre instance de base de données Amazon RDS. L'activation des sauvegardes automatiques garantit que vous pouvez restaurer votre réplica sur un instant donné si vous devez resynchroniser votre instance source et votre réplica. Pour plus d'informations sur les sauvegardes et les point-in-time restaurations, consultez[Sauvegarde, restauration et exportation de données](CHAP_CommonTasks.BackupRestore.md).
**Pour configurer une réplication de position de fichier journal binaire avec une instance source externe**
1. Rendez l'instance MySQL ou MariaDB source accessible 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 source MySQL ou MariaDB 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 externe vers l'instance de base de données Amazon RDS à l'aide de `mysqldump`. Pour les bases de données très volumineuses, il se peut que vous vouliez utiliser la procédure décrite dans [Importation de données vers une base de données Amazon RDS for MySQL avec une durée d’indisponibilité réduite](mysql-importing-data-reduced-downtime.md).
Pour Linux, macOS ou Unix :
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u local_user \
-plocal_password | mysql \
--host=hostname \
--port=3306 \
-u RDS_user_name \
-pRDS_password
```
Pour Windows :
```
mysqldump --databases database_name ^
--single-transaction ^
--compress ^
--order-by-primary ^
-u local_user ^
-plocal_password | mysql ^
--host=hostname ^
--port=3306 ^
-u RDS_user_name ^
-pRDS_password
```
**Note**
Veillez bien à ce qu’il n’y ait pas d’espace entre l’option `-p` et le mot de passe saisi.
Pour spécifier le nom d’hôte, le nom d’utilisateur, le port et le mot de passe afin de vous connecter à votre instance de base de données Amazon RDS, utilisez les options `--host`, `--user (-u)`, `--port` et `-p` dans la commande `mysql`. Le nom d'hôte est le nom DNS du point de terminaison de l'instance de base de données Amazon RDS : par exemple `myinstance.123456789012.us-east-1.rds.amazonaws.com`. Vous pouvez trouver la valeur du point de terminaison dans la AWS Management Console au niveau des détails de l’instance.
1. Rendez l'instance source MySQL ou MariaDB à nouveau accessible en écriture.
```
mysql> SET GLOBAL read_only = OFF;
mysql> UNLOCK TABLES;
```
Pour plus d’informations sur la création de sauvegardes en vue de les utiliser avec la réplication, consultez [la documentation MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-solutions-backups-read-only.html).
1. Dans le AWS Management Console, ajoutez l'adresse IP du serveur qui héberge la base de données externe au groupe de sécurité du cloud privé virtuel (VPC) pour l'instance de base de données Amazon RDS. 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*.
L'adresse IP peut changer lorsque les conditions suivantes sont réunies :
+ Vous utilisez une adresse IP publique pour la communication entre l'instance source externe et l'instance de base de données.
+ L'instance source externe a été arrêtée et redémarrée.
Si ces conditions sont réunies, vérifiez l'adresse IP avant de l'ajouter.
Vous devrez peut-être aussi configurer votre réseau local pour autoriser les connexions à partir de l'adresse IP de votre instance de base de données Amazon RDS. Cela permet la communication entre votre réseau local et votre instance MySQL ou MariaDB externe. Pour obtenir l'adresse IP de l'instance de base de données Amazon RDS, utilisez la commande `host`.
```
host db_instance_endpoint
```
Le nom d'hôte est le nom DNS du point de terminaison de l'instance de base de données Amazon RDS.
1. En utilisant le client de votre choix, connectez-vous à l’instance externe et créez un utilisateur à utiliser pour la réplication. Utilisez ce compte exclusivement pour la réplication et limitez-le à votre domaine pour améliorer la sécurité. Voici un exemple.
```
CREATE USER 'repl_user'@'mydomain.com' IDENTIFIED BY 'password';
```
**Note**
Spécifiez un mot de passe autre que celui indiqué ici, en tant que bonne pratique de sécurité.
1. Pour l’instance 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'@'mydomain.com';
```
1. Transformez l'instance de base de données Amazon RDS en réplica. Pour cela, connectez-vous d’abord à l’instance de base de données Amazon RDS en tant qu’utilisateur principal. Identifiez ensuite la base de données MySQL ou MariaDB externe comme instance source à l’aide de la commande [mysql.rds\$1set\$1external\$1source (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source) ou [mysql.rds\$1set\$1external\$1master (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master). Utilisez le nom et la position du fichier journal maître que vous avez déterminés à l’étape 2. Les commandes suivantes sont des exemples.
**MySQL 8.4**
```
CALL mysql.rds_set_external_source ('mysourceserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**MariaDB et MySQL 8.0 et 5.7**
```
CALL mysql.rds_set_external_master ('mymasterserver.mydomain.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1);
```
**Note**
Sur RDS for MySQL, vous pouvez décider d’utiliser la réplication différée en exécutant à la place la procédure stockée [mysql.rds\$1set\$1external\$1source\$1with\$1delay (RDS for MySQL, versions majeures 8.4 et ultérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_source_with_delay) ou [mysql.rds\$1set\$1external\$1master\$1with\$1delay (RDS for MariaDB et RDS for MySQL, versions majeures 8.0 et antérieures)](mysql-stored-proc-replicating.md#mysql_rds_set_external_master_with_delay). Sur RDS for MySQL, une des raisons d’utiliser la réplication différée est d’activer la reprise après sinistre avec la procédure stockée [](mysql-stored-proc-replicating.md#mysql_rds_start_replication_until). Actuellement, RDS for MariaDB prend en charge la réplication différée, mais ne prend pas en charge la procédure `mysql.rds_start_replication_until`.
1. Sur l’instance de base de données Amazon RDS, émettez la commande [mysql.rds\$1start\$1replication](mysql-stored-proc-replicating.md#mysql_rds_start_replication) pour démarrer la réplication.
```
CALL mysql.rds_start_replication;
```
# Configuration multi-source-replication pour Amazon RDS for MySQL
La réplication multisource vous permet de configurer une instance de base de données Amazon RDS for MySQL en tant que réplique qui reçoit les événements du journal binaire de plusieurs instances de base de données sources RDS for MySQL. La réplication multisource est prise en charge pour les instances de base de données RDS for MySQL qui exécutent les versions de moteur suivantes :
+ Toutes les versions 8.4 de MySQL
+ 8.0.35 et versions mineures ultérieures
+ 5.7.44 et versions mineures ultérieures
Pour plus d’informations sur la réplication multisource MySQL, consultez [Réplication multisource MySQL](https://dev.mysql.com/doc/refman/8.0/en/replication-multi-source.html) dans la documentation MySQL. La documentation MySQL contient des informations détaillées sur cette fonctionnalité. Cette rubrique décrit quant à elle comment configurer et gérer les canaux de réplication multisource sur vos instances de base de données RDS for MySQL.
## Cas d’utilisation de la réplication multisource
Les cas suivants sont idéaux pour l’utilisation de la réplication multisource sur RDS for MySQL :
+ Applications qui doivent fusionner ou combiner plusieurs partitions sur des instances de base de données distinctes en une seule partition.
+ Applications qui doivent générer des rapports à partir de données consolidées provenant de plusieurs sources.
+ Exigences relatives à la création de sauvegardes consolidées à long terme des données distribuées entre plusieurs instances de base de données RDS for MySQL.
## Conditions préalables pour la réplication multisource
Avant de configurer une réplication multisource, remplissez les conditions préalables suivantes.
+ Assurez-vous que les sauvegardes automatiques sont activées pour chaque instance de base de données source RDS for MySQL. L’activation des sauvegardes automatiques active la journalisation binaire. Pour découvrir comment activer des sauvegardes automatiques, consultez [Activation des sauvegardes automatiques](USER_WorkingWithAutomatedBackups.Enabling.md).
+ Pour éviter les erreurs de réplication, nous vous recommandons de bloquer les opérations d’écriture sur les instances de base de données sources. Pour cela, vous pouvez définir le paramètre `read-only` sur `ON` dans un groupe de paramètres personnalisé attaché à l’instance de base de données source RDS for MySQL. Vous pouvez utiliser le AWS Management Console ou le AWS CLI pour créer un nouveau groupe de paramètres personnalisés ou pour modifier un groupe existant. Pour plus d’informations, consultez [Création d’un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Creating.md) et [Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS](USER_WorkingWithParamGroups.Modifying.md).
+ Pour chaque instance de base de données source, ajoutez l’adresse IP de l’instance au groupe de sécurité du cloud privé virtuel (VPC) Amazon pour l’instance de base de données multisource. Pour identifier l’adresse IP d’une instance de base de données source, vous pouvez exécuter la commande `dig RDS Endpoint`. Exécutez la commande à partir d’une instance Amazon EC2 dans le même VPC que l’instance de base de données multisource de destination.
+ Pour chaque instance de base de données source, utilisez un client pour vous y connecter et créez un utilisateur de base de données doté des privilèges requis pour la réplication, comme dans l’exemple suivant.
```
CREATE USER 'repl_user' IDENTIFIED BY 'password';
GRANT REPLICATION CLIENT, REPLICATION SLAVE ON *.* TO 'repl_user';
```
**Note**
À partir de MySQL 8.4, le privilège `REPLICATION SLAVE` est devenu obsolète et a été remplacé par `REPLICATION REPLICA`. Pour MySQL 8.4 et versions ultérieures, utilisez plutôt la syntaxe suivante :
```
CREATE USER 'repl_user' IDENTIFIED BY 'password';
GRANT REPLICATION CLIENT, REPLICATION REPLICA ON *.* TO 'repl_user';
```
## Configuration de canaux de réplication multisource sur les instances de base de données RDS for MySQL
La configuration des canaux de réplication multisource est similaire à la configuration de la réplication à source unique. Pour la réplication multisource, vous devez d’abord activer la journalisation binaire sur l’instance source. Vous importez ensuite les données des sources vers la réplique multisource. Ensuite, vous lancez la réplication à partir de chaque source en utilisant les coordonnées des journaux binaires ou en utilisant le positionnement automatique GTID.
Pour configurer une instance de base de données RDS for MySQL en tant que réplique multisource d’au moins deux instances de base de données RDS for MySQL, suivez les étapes ci-dessous.
**Topics**
+ [
### Étape 1 : Importer les données des instances de base de données source vers la réplique multisource
](#mysql-multi-source-replication-import)
+ [
### Étape 2 : Démarrer la réplication à partir des instances de base de données source vers la réplique multisource
](#mysql-multi-source-replication-setting-up-start-replication-other)
### Étape 1 : Importer les données des instances de base de données source vers la réplique multisource
Procédez comme suit sur chaque instance de base de données source.
Avant d’importer les données d’une source vers la réplique multisource, déterminez le fichier journal binaire actuel et sa position en exécutant la commande `SHOW MASTER STATUS`. Vous devez prendre note de ces informations pour les utiliser lors de l’étape suivante. Dans cet exemple de sortie, le fichier est `mysql-bin-changelog.000031` et la position est `107`.
**Note**
À partir de MySQL 8.4, la commande `SHOW MASTER STATUS` est devenue obsolète et a été remplacée par `SHOW BINARY LOG STATUS`. Pour MySQL 8.4 et versions ultérieures, utilisez plutôt `SHOW BINARY LOG STATUS`.
```
File Position
-----------------------------------
mysql-bin-changelog.000031 107
-----------------------------------
```
Copiez maintenant la base de données de l’instance de base de données source vers la réplique multisource en utilisant `mysqldump`, comme dans l’exemple suivant.
```
mysqldump --databases database_name \
--single-transaction \
--compress \
--order-by-primary \
-u RDS_user_name \
-p RDS_password \
--host=RDS Endpoint | mysql \
--host=RDS Endpoint \
--port=3306 \
-u RDS_user_name \
-p RDS_password
```
Après avoir copié la base de données, vous pouvez définir le paramètre en lecture seule sur `OFF` sur l’instance de base de données source.
### Étape 2 : Démarrer la réplication à partir des instances de base de données source vers la réplique multisource
Pour chaque instance de base de données source, utilisez les informations d’identification de l’utilisateur administratif pour vous connecter à l’instance et exécutez les deux procédures stockées suivantes. Ces procédures stockées configurent la réplication sur un canal et démarrent la réplication. Cet exemple utilise le nom et la position du fichier binlog à partir de l’exemple de sortie de l’étape précédente.
```
CALL mysql.rds_set_external_source_for_channel('mysourcehost.example.com', 3306, 'repl_user', 'password', 'mysql-bin-changelog.000031', 107, 1, 'channel_1');
CALL mysql.rds_start_replication_for_channel('channel_1');
```
Pour plus d’informations sur l’utilisation de ces procédures stockées et d’autres afin de configurer et de gérer vos canaux de réplication, consultez [Gestion de la réplication multisource](mysql-stored-proc-multi-source-replication.md).
## Utilisation de filtres avec la réplication multisource
Vous pouvez utiliser des filtres de réplication pour spécifier quelles bases de données et tables sont répliquées avec une réplique multisource. Les filtres de réplication peuvent inclure des bases de données et des tables dans la réplication ou les en exclure. Pour plus d’informations sur les filtres de réplication, consultez [Configuration des filtres de réplication avec MySQL](USER_MySQL.Replication.ReadReplicas.ReplicationFilters.md).
Avec la réplication multisource, vous pouvez configurer les filtres de réplication globalement ou au niveau du canal. Le filtrage au niveau du canal n’est disponible qu’avec les instances de base de données prises en charge exécutant la version 8.0 ou 8.4. Les exemples suivants montrent comment configurer des filtres globalement ou au niveau du canal.
Notez les exigences et le comportement suivants concernant le filtrage dans la réplication multisource :
+ Les noms des canaux doivent être placés entre guillemets (``).
+ Si vous modifiez les filtres de réplication dans le groupe de paramètres, le `sql_thread` des répliques multisource de tous les canaux mis à jour est redémarré de manière à appliquer les modifications de manière dynamique. Si une mise à jour implique un filtre global, tous les canaux de réplication en cours d’exécution sont redémarrés.
+ Tous les filtres globaux sont appliqués avant les filtres spécifiques au canal.
+ Si un filtre est appliqué globalement et au niveau du canal, seul celui au niveau du canal est appliqué. Par exemple, si les filtres sont `replicate_ignore_db="db1,`channel_22`:db2"`, `replicate_ignore_db` défini sur `db1` est appliqué à tous les canaux sauf `channel_22`, et seul `channel_22` ignore les modifications de `db2`.
Exemple 1 : Définition d’un filtre global
Dans l’exemple suivant, la base de données `temp_data` est exclue de la réplication sur tous les canaux.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-ignore-db,ParameterValue='temp_data',ApplyMethod=immediate"
```
Exemple 2 : Définition d’un filtre au niveau du canal
Dans l’exemple suivant, les modifications apportées à la base de données `sample22` ne sont incluses que dans le canal `channel_22`. De même, les modifications apportées à la base de données `sample99` ne sont incluses que dans le canal `channel_99`.
Pour Linux, macOS ou Unix :
```
aws rds modify-db-parameter-group \
--db-parameter-group-name myparametergroup \
--parameters "ParameterName=replicate-do-db,ParameterValue='\`channel_22\`:sample22,\`channel_99\`:sample99',ApplyMethod=immediate"
```
## Surveillance des canaux de réplication multisource
Vous pouvez surveiller des canaux individuels dans une réplique multisource en utilisant les méthodes suivantes :
+ Pour surveiller l’état de tous les canaux ou d’un canal spécifique, connectez-vous à la réplique multisource et exécutez la commande `SHOW REPLICA STATUS` ou `SHOW REPLICA STATUS FOR CHANNEL 'channel_name'`. Pour plus d’informations, 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.
+ Pour recevoir une notification lorsqu’un canal de réplication est démarré, arrêté ou supprimé, utilisez la notification d’événement RDS. Pour plus d’informations, consultez [Utiliser la notification d'événements d'Amazon RDS](USER_Events.md).
+ Pour surveiller le décalage d’un canal spécifique, vérifiez la métrique `ReplicationChannelLag` correspondante. Les points de données pour cette métrique, d’une durée de 60 secondes (1 minute), sont disponibles pendant 15 jours. Pour déterminer le décalage d’un canal de réplication, utilisez l’identifiant de l’instance et le nom du canal de réplication. Pour recevoir une notification lorsque ce décalage dépasse un certain seuil, vous pouvez configurer une CloudWatch alarme. Pour de plus amples informations, veuillez consulter [Surveillance des métriques Amazon RDS () avec Amazon CloudWatch](monitoring-cloudwatch.md).
## Considérations et pratiques exemplaires pour la réplication multisource
Avant d’utiliser la réplication multisource sur RDS for MySQL, passez en revue les considérations et les pratiques exemplaires suivantes :
+ Assurez-vous qu’une instance de base de données configurée en tant que réplique multisource dispose de ressources suffisantes telles que le débit, la mémoire, le processeur et les IOPS pour gérer la charge de travail provenant de plusieurs instances sources.
+ Surveillez régulièrement l’utilisation des ressources sur votre réplique multisource et ajustez la configuration du stockage ou de l’instance pour gérer la charge de travail sans surcharger les ressources.
+ Vous pouvez configurer la réplication multithread sur une réplique multisource en définissant la variable système `replica_parallel_workers` sur une valeur supérieure à `0`. Dans ce cas, le nombre de threads alloués à chaque canal est la valeur de cette variable, plus un thread coordinateur pour gérer les threads applicateurs.
+ Configurez correctement les filtres de réplication pour éviter les conflits. Pour répliquer une base de données complète vers une autre base de données sur une réplique, vous pouvez utiliser l’option `--replicate-rewrite-db`. Par exemple, vous pouvez répliquer toutes les tables de la base de données A vers la base de données B sur une instance de réplication. Cette approche peut être utile lorsque toutes les instances sources utilisent la même convention de dénomination de schéma. Pour plus d’informations sur l’option `--replicate-rewrite-db`, consultez [Options et variables de serveur de réplique](https://dev.mysql.com/doc/refman/8.0/en/replication-options-replica.html) dans la documentation MySQL.
+ Pour éviter les erreurs de réplication, évitez d’écrire sur la réplique. Nous vous recommandons d’activer le paramètre `read_only` sur les répliques multisource pour bloquer les opérations d’écriture. Cela permet d’éliminer les problèmes de réplication causés par des opérations d’écriture contradictoires.
+ Pour améliorer les performances des opérations de lecture telles que les tris et les jointures à charge élevée exécutées sur la réplique multisource, pensez à utiliser RDS Optimized Reads. Cette fonctionnalité peut être utile pour les requêtes qui dépendent de grandes tables temporaires ou de fichiers de tri. Pour de plus amples informations, veuillez consulter [Amélioration des performances des requêtes pour RDS for MySQL avec Lectures optimisées pour Amazon RDS](rds-optimized-reads.md).
+ Pour minimiser le délai de réplication et améliorer les performances d’une réplique multisource, pensez à activer les écritures optimisées. Pour de plus amples informations, veuillez consulter [Amélioration des performances d'écriture avec Écritures optimisées pour RDS for MySQL](rds-optimized-writes.md).
+ Effectuez des opérations de gestion (telles que la modification de la configuration) sur un canal à la fois et évitez de modifier plusieurs canaux à partir de plusieurs connexions. Ces pratiques peuvent entraîner des conflits dans les opérations de réplication. Par exemple, l’exécution simultanée de procédures `rds_skip_repl_error_for_channel` et `rds_start_replication_for_channel` à partir de plusieurs connexions peut entraîner l’omission d’événements sur un canal différent de celui prévu.
+ Vous pouvez activer les sauvegardes sur une instance de réplication multisource et exporter les données de cette instance vers un compartiment Amazon S3 afin de les stocker à long terme. Cependant, il est également important de configurer les sauvegardes avec une rétention appropriée sur les instances sources individuelles. Pour plus d’informations sur l’exportation de données d’instantanés vers Amazon S3, consultez [Exportation de données d’instantanés de bases de données vers Amazon S3 pour Amazon RDS](USER_ExportSnapshot.md).
+ Pour répartir la charge de travail de lecture sur une réplique multisource, vous pouvez créer des répliques de lecture à partir d’une réplique multisource. Vous pouvez localiser ces répliques de lecture de différentes manières en Régions AWS fonction des exigences de votre application. Pour plus d’informations sur les réplicas en lecture, consultez [Utilisation de réplicas en lecture MySQL](USER_MySQL.Replication.ReadReplicas.md).
## Limitations de la réplication multisource sur RDS for MySQL
Les limitations suivantes s’appliquent à la réplication multisource pour RDS for MySQL :
+ Actuellement, RDS for MySQL prend en charge la configuration d’un maximum de 15 canaux pour une réplique multisource.
+ Une instance de réplication en lecture ne peut pas être configurée en tant que réplique multisource.
+ Le schéma de performance doit être activé sur l’instance de réplique pour que vous puissiez configurer la réplication multisource sur RDS for MySQL exécutant le moteur version 5.7. L’activation du schéma de performance est facultative sur RDS for MySQL exécutant le moteur version 8.0 ou 8.4.
+ Pour RDS for MySQL exécutant le moteur version 5.7, les filtres de réplication s’appliquent à tous les canaux de réplication. Pour RDS for MySQL exécutant le moteur version 8.0 ou 8.4, vous pouvez configurer des filtres qui s’appliquent à tous les canaux de réplication ou à des canaux individuels.
+ La restauration d'un instantané RDS ou l'exécution d'un Point-in-time-Restore (PITR) ne restaurent pas les configurations de canaux de réplication multi-sources.
+ Lorsque vous créez une réplique en lecture d’une réplique multisource, elle ne réplique que les données de l’instance multisource. Elle ne restaure pas la configuration d’un canal.
+ MySQL ne prend pas en charge la configuration d’un nombre différent de travailleurs parallèles pour chaque canal. Chaque canal reçoit le même nombre de travailleurs parallèles en fonction de la valeur `replica_parallel_workers`.
Les limitations supplémentaires suivantes s’appliquent si votre cible de réplication multisource est un cluster de bases de données Multi-AZ :
+ Un canal doit être configuré pour une instance source RDS for MySQL avant toute écriture sur cette instance.
+ La réplication basée sur GTID doit être activée sur chaque instance source RDS for MySQL.
+ Un événement de basculement sur le cluster de bases de données supprime la configuration de réplication multisource. Pour restaurer cette configuration, il est nécessaire de répéter les étapes de configuration.