Configuration de la réplication multisource pour Amazon RDS for MySQL - Amazon Relational Database Service
Cas d’utilisationPrérequisConfiguration des canaux de réplication multisourceUtilisation de filtresSurveillance des canaux de réplication multisourceConsidérations et pratiques exemplairesLimitations

Configuration de la réplication multisource 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 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.

  • 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 la AWS Management Console ou l’AWS CLI pour créer un nouveau groupe de paramètres personnalisés ou pour en modifier un existant. Pour plus d’informations, consultez Création d’un groupe de paramètres de base de données dans Amazon RDS et Modification de paramètres dans un groupe de paramètres de base de données dans Amazon RDS.

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

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

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.

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

  • 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 alarme CloudWatch. Pour plus d’informations, consultez Surveillance des métriques Amazon RDS avec Amazon CloudWatch.

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 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 plus d’informations, consultez Amélioration des performances des requêtes pour RDS for MySQL avec Lectures optimisées pour Amazon RDS.

  • 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 plus d’informations, consultez Amélioration des performances d'écriture avec Écritures optimisées pour RDS for MySQL.

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

  • 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 dans différentes Régions AWS en fonction des exigences de votre application. Pour plus d’informations sur les réplicas en lecture, consultez Utilisation de réplicas en lecture MySQL.

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’une restauration ponctuelle (PITR) ne restaurent pas les configurations de canaux de réplication multisource.

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