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