Configuration multi-source-replication pour RDS pour MySQL - Amazon Relational Database Service

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 RDS pour MySQL

Avec la réplication multi-source, vous pouvez configurer une instance de base de données Amazon RDS pour MySQL en tant que réplique qui reçoit les événements du journal binaire de plusieurs instances de base de données source RDS pour MySQL. La réplication multi-source est prise en charge pour les instances de base de données RDS for MySQL exécutant les versions de moteur suivantes :

  • Versions mineures 8.0.35 et supérieures

  • Versions mineures 5.7.44 et supérieures

Pour plus d'informations sur la réplication multi-source MySQL, consultez la section Réplication multi-source MySQL dans la documentation MySQL. La documentation MySQL contient des informations détaillées sur cette fonctionnalité, tandis que cette rubrique décrit comment configurer et gérer les canaux de réplication multi-sources sur vos instances de base de données RDS pour MySQL.

Cas d'utilisation de la réplication multi-sources

Les cas suivants sont de bons candidats pour l'utilisation de la réplication multi-source 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 devant générer des rapports à partir de données consolidées provenant de sources multiples.

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

Considérations et bonnes pratiques relatives à la réplication multi-sources

Avant d'utiliser la réplication multi-source sur RDS pour MySQL, passez en revue les considérations et les meilleures pratiques suivantes :

  • Assurez-vous qu'une instance de base de données configurée en tant que réplique multi-source 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 multi-source 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 multi-source en définissant la variable système replica_parallel_workers ou en lui attribuant une valeur supérieure slave_parallel_workers à 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 les filtres de réplication de manière appropriée pour éviter les conflits. Vous pouvez configurer replica_rewrite_db pour répliquer une base de données complète vers une autre base de données sur un réplica. Par exemple, toutes les tables de la base de données A peuvent être répliquées dans la base de données B sur une instance de réplication. Cette approche peut être utile lorsque toutes les instances source utilisent la même convention de dénomination de schéma.

  • Pour éviter les erreurs de réplication, évitez d'écrire sur le réplica. Nous vous recommandons d'activer le read_only paramètre sur les répliques multi-sources 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 multi-source, pensez à utiliser des lectures optimisées RDS. 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 Amazon RDS Optimized Reads.

  • Pour minimiser le délai de réplication et améliorer les performances d'une réplique multi-sources, 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 rds_skip_repl_error_for_channel de rds_start_replication_for_channel procédures à 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 multi-sources et exporter les données de cette instance vers un compartiment Amazon S3 afin de les stocker à des fins de 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 de capture d'écran vers Amazon S3, consultezExportation de données d'instantanés de bases de données vers Amazon S3.

  • Pour répartir la charge de travail de lecture sur un réplica multi-source, vous pouvez créer des répliques de lecture à partir d'un réplica multi-sources. 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.

Conditions préalables à la réplication multi-sources

Avant de configurer la réplication multi-source, remplissez les conditions préalables suivantes.

  • Assurez-vous que les sauvegardes automatiques sont activées pour chaque instance de base de données RDS pour MySQL source. L'activation des sauvegardes automatiques active la journalisation binaire. Pour savoir comment activer les sauvegardes automatiques, consultezActivation 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 source. Vous pouvez le faire en définissant le read-only paramètre sur ON dans un groupe de paramètres personnalisé attaché à l'instance de base de données source RDS pour 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 bases de données et Modification de paramètres dans un groupe de paramètres de bases de données.

  • Pour chaque instance de base de données source, ajoutez l'adresse IP de l'instance au groupe de sécurité Amazon Virtual Private Cloud (VPC) pour l'instance de base de données multi-source. Pour identifier l'adresse IP d'une instance de base de données source, vous pouvez exécuter la commandedig RDS Endpoint. Exécutez la commande depuis une instance Amazon EC2 dans le même VPC que l'instance de base de données multi-source de destination.

  • Pour chaque instance de base de données source, utilisez un client pour vous connecter à l'instance de base de données 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';

Configuration de canaux de réplication multi-sources sur RDS pour les instances de base de données MySQL

La configuration de canaux de réplication à sources multiples est similaire à la configuration de la réplication à source unique. Pour la réplication multi-source, vous devez d'abord activer la journalisation binaire sur l'instance source. Vous importez ensuite les données des sources vers la réplique multi-sources. Ensuite, vous lancez la réplication à partir de chaque source en utilisant les coordonnées binaires du journal ou en utilisant le positionnement automatique GTID.

Pour configurer une instance de base de données RDS pour MySQL en tant que réplique multi-source de deux instances de base de données RDS pour MySQL ou plus, effectuez les étapes suivantes.

Étape 1 : Importer les données des instances de base de données source vers la réplique multi-source

Effectuez les étapes suivantes sur chaque instance de base de données source.

Avant d'importer les données d'une source vers la réplique multi-source, déterminez le fichier journal binaire actuel et sa position en exécutant la SHOW MASTER STATUS commande. Prenez note de ces informations pour les utiliser à l'étape suivante. Dans cet exemple de sortie, le fichier est mysql-bin-changelog.000031 et la position est107.

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 multi-source en utilisantmysqldump, 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 OFF sur l'instance de base de données source.

Étape 2 : démarrer la réplication depuis les instances de base de données source vers la réplique multi-source

Pour chaque instance de base de données source, utilisez les informations d'identification de l'utilisateur principal 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 indiqués dans 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, 0, '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 pour configurer et gérer vos canaux de réplication, consultezGestion de la réplication multi-sources.

Utilisation de filtres avec réplication multi-sources

Vous pouvez utiliser des filtres de réplication pour spécifier les bases de données et les tables qui sont répliquées dans une réplique multi-sources. 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. Pour plus d'informations sur les filtres de réplication, consultezConfiguration des filtres de réplication avec MySQL.

Avec la réplication multi-sources, 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. Les exemples suivants montrent comment configurer les filtres globalement ou au niveau du canal.

Notez les exigences et le comportement suivants en matière de filtrage dans le cadre de la réplication multi-sources :

  • Les noms des chaînes doivent être placés entre guillemets (``).

  • Si vous modifiez les filtres de réplication dans le groupe de paramètres, les répliques multi-sources de tous les canaux mis à jour sont redémarrées sql_thread pour 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 le filtre au niveau du canal est appliqué. Par exemple, si les filtres le sontreplicate_ignore_db="db1,`channel_22`:db2", le paramètre replicate_ignore_db défini sur db1 est appliqué à tous les canaux à l'exception dechannel_22, et channel_22 ignore uniquement les modifications dedb2.

Exemple 1 : définition d'un filtre global

Dans l'exemple suivant, la temp_data base de données est exclue de la réplication sur tous les canaux.

Pour LinuxmacOS, 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 sample22 base de données ne sont incluses que dans le canalchannel_22. De même, les modifications apportées à la sample99 base de données ne sont incluses que dans le canalchannel_99.

Pour LinuxmacOS, 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 multi-sources

Vous pouvez surveiller des canaux individuels dans une réplique multi-sources 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 multi-source et exécutez la SHOW REPLICA STATUS FOR CHANNEL 'channel_name' commande SHOW REPLICA STATUS or. Pour plus d'informations, consultez Vérifier l'état de 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 ReplicationChannelLag métrique correspondante. Les points de données pour cette métrique ont une période de 60 secondes (1 minute) et 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 plus d'informations, consultez Surveillance des métriques Amazon RDS avec Amazon CloudWatch.

Limitations de la réplication multi-source sur RDS pour MySQL

Les limitations suivantes s'appliquent à la réplication multi-source sur RDS pour MySQL :

  • Actuellement, RDS for MySQL prend en charge la configuration d'un maximum de 15 canaux pour une réplique multi-sources.

  • Une instance de réplication en lecture ne peut pas être configurée en tant que réplique multi-source.

  • Pour configurer la réplication multi-source sur RDS pour MySQL exécutant le moteur version 5.7, le schéma de performance doit être activé sur l'instance de réplique. L'activation du schéma de performance est facultative sur RDS pour MySQL exécutant le moteur version 8.0.

  • 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, 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 P oint-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 multi-source, elle ne réplique que les données de l'instance multi-source. Il ne restaure aucune configuration de 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 replica_parallel_workers valeur.

Les limitations supplémentaires suivantes s'appliquent si votre cible de réplication multi-source est un cluster de base de données multi-AZ :

  • Un canal doit être configuré pour une instance source RDS pour MySQL avant toute écriture sur cette instance.

  • La réplication basée sur GTID doit être activée pour chaque instance source RDS pour MySQL.

  • Un événement de basculement sur le cluster de base de données supprime la configuration de réplication multi-source. La restauration de cette configuration nécessite de répéter les étapes de configuration.