View a markdown version of this page

Configuration de la réplication multisource pour Amazon Aurora MySQL - Amazon Aurora
Cas d’utilisation de la réplication multisourceConditions préalables pour la réplication multisourceConfiguration de canaux de réplication multisources sur des clusters de bases de données Aurora MySQLUtiliser des filtres avec réplication multi-sourcesSurveillez les canaux de réplication multisourcesGestion des procédures stockées de réplication multi-sourcesConsidérations et pratiques exemplairesLimitationsRésolution des problèmesExemple : configuration multisource complète avec trois sourcesRessources connexes

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 de la réplication multisource pour Amazon Aurora MySQL

Avec la réplication multisource, vous pouvez configurer un cluster de bases de données Amazon Aurora MySQL en tant que réplique qui reçoit des événements de journal binaires provenant de plusieurs bases de données MySQL sources. Chaque source peut être une instance de base de données RDS pour MySQL, un autre cluster de bases de données Aurora MySQL ou une base de données MySQL exécutée en dehors d'Amazon RDS.

Multi-source la réplication est prise en charge pour les clusters de bases de données Aurora MySQL exécutant les versions de moteur suivantes :

  • Aurora MySQL 8.4.8 et versions ultérieures

Pour plus d'informations sur la réplication multisource MySQL, consultez la section Multi-Source Réplication MySQL dans la documentation MySQL.

Note

Multi-source la réplication sur Aurora MySQL utilise l'instance d'écriture (principale) du cluster de base de données Aurora comme cible de réplication. Toutes les procédures stockées de réplication doivent être appelées lorsqu'elles sont connectées à l'instance d'écriture du cluster.

Cas d’utilisation de la réplication multisource

Envisagez d'utiliser la réplication multisource sur Aurora MySQL dans les cas suivants :

  • Consolidation des partitions  : applications qui ont besoin de fusionner ou de combiner des données provenant de plusieurs partitions hébergées sur des instances de bases de données distinctes dans un seul cluster de bases de données Aurora MySQL.

  • Rapports consolidés  : applications qui doivent générer des rapports à partir de données consolidées provenant de sources multiples, en tirant parti des capacités de dimensionnement de la lecture d'Aurora.

  • Long-term sauvegardes  : exigences pour créer des sauvegardes consolidées à long terme des données distribuées entre plusieurs instances de MySQL-compatible bases de données.

  • Cross-engine migration  : consolidation des données provenant de plusieurs instances RDS pour MySQL ou de serveurs MySQL externes dans un seul cluster Aurora MySQL pendant la migration.

  • Multi-tenant agrégation  : consolidation de plusieurs bases de données à locataire unique dans un cluster Aurora mutualisé pour optimiser les coûts et simplifier la gestion.

Conditions préalables pour la réplication multisource

Avant de configurer la réplication multisource sur votre cluster de bases de données Aurora MySQL, remplissez les conditions requises standard pour la réplication des journaux binaires, comme décrit dans. Configuration de la réplication des journaux binaires pour Aurora MySQL Cela inclut l'activation de la journalisation binaire sur chaque source, la conservation des journaux binaires, la création d'un utilisateur de réplication et la création d'une copie ou d'un vidage de chaque source. Pour la réplication multisource, répétez ces étapes pour chaque instance de base de données source.

Outre les prérequis standard, assurez-vous de respecter les exigences suivantes spécifiques à la réplication multisource.

  • Vérifiez la version et la configuration du cluster cible Aurora MySQL

    • Le cluster de base de données Aurora MySQL doit exécuter une version de moteur prise en charge (Aurora MySQL 8.4.8 et versions ultérieures).

    • Activez la validation automatique sur l'instance Aurora MySQL Writer. Définissez le autocommit paramètre 1 dans le groupe de paramètres de votre cluster de bases de données.

  • Configurer la connectivité réseau pour chaque source

    Pour chaque instance de base de données source, assurez-vous que l'instance d'écriture Aurora MySQL peut se connecter à la source sur le port spécifié. Voici les options :

    • Si la source et la cible se trouvent dans le même VPC, configurez le groupe de sécurité sur l'instance de base de données source pour autoriser les connexions entrantes sur le port 3306 (ou votre port personnalisé) à partir du groupe de sécurité du cluster Aurora MySQL.

    • S'ils se trouvent dans des VPC différents, configurez le peering VPC ou utilisez une passerelle de transit. Pour de plus amples informations, veuillez consulter UNE BASE DE DONNÉES cluster dans un VPC auquel accède une instance EC2 dans un autre VPC.

    • Si la source est externe à AWS, assurez-vous que les itinéraires réseau sont disponibles (par exemple, via ou via une connexion VPN).

Note

La réplication multisource impliquant plusieurs sources, vous devez vérifier la connectivité à chaque source indépendamment. Assurez-vous que les groupes de sécurité et le routage prennent en charge tous les points de terminaison sources simultanément.

Configuration de canaux de réplication multisources sur des clusters de bases de données Aurora MySQL

La configuration de canaux de réplication multisources sur Aurora MySQL est similaire à la configuration de la réplication à source unique. Pour la réplication multi-sources, vous devez d'abord activer la journalisation binaire sur les instances sources, importer des données depuis les sources vers le cluster Aurora MySQL, puis démarrer la réplication depuis chaque source à l'aide des coordonnées du journal binaire ou du positionnement automatique GTID.

Important

Toutes les procédures stockées de réplication multi-sources doivent être appelées lorsqu'elles sont connectées à l'instance d'écriture du cluster de bases de données Aurora MySQL. En cas de basculement, vous devez vous reconnecter à la nouvelle instance d'écriture.

Étape 1 : importer des données depuis les instances de base de données source vers le cluster Aurora MySQL

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

  1. Déterminez le fichier journal binaire actuel et sa position sur l'instance de base de données source.

    Pour MySQL 8.4
    SHOW BINARY LOG STATUS;
    Pour MySQL 8.0 et versions antérieures
    SHOW MASTER STATUS;

    Exemple de sortie :

    +----------------------------+----------+
| File                       | Position |
+----------------------------+----------+
| mysql-bin-changelog.000031 |      107 |
+----------------------------+----------+

    Enregistrez les Position valeurs File et. Vous en aurez besoin ultérieurement.

  2. Copiez la base de données de l'instance de base de données source vers le cluster Aurora MySQL à l'aide demysqldump.

    mysqldump --databases database_name \
  --single-transaction \
  --compress \
  --order-by-primary \
  -u RDS_user_name \
  -p'RDS_password' \
  --host=source-endpoint.region.rds.amazonaws.com | mysql \
  --host=aurora-cluster-endpoint.cluster-xxxxxx.region.rds.amazonaws.com \
  --port=3306 \
  -u aurora_user_name \
  -p'aurora_password'
    Astuce

    Pour les bases de données volumineuses, envisagez d'utiliser AWS DMS ou de créer un instantané et de le restaurer afin de réduire le temps de transfert des données.

  3. Une fois l'importation des données terminée, vous pouvez réactiver les écritures sur l'instance de base de données source si vous l'aviez précédemment configurée en lecture seule.

Étape 2 : démarrer la réplication depuis les instances de base de données source vers le cluster Aurora MySQL

Pour chaque instance de base de données source, connectez-vous à l'instance d'écriture du cluster de bases de données Aurora MySQL et exécutez les procédures stockées pour configurer et démarrer la réplication sur un canal.

Option A : Utilisation de la position du fichier journal binaire
CALL mysql.rds_set_external_source_for_channel(
  'source-endpoint.region.rds.amazonaws.com',
  3306,
  'repl_user',
  'password',
  'mysql-bin-changelog.000031',
  107,
  0,
  'channel_1'
);

CALL mysql.rds_start_replication_for_channel('channel_1');
Option B : Utilisation du positionnement automatique du GTID

Si vos instances de bases de données source utilisent GTID-based la réplication, vous pouvez utiliser le positionnement automatique au lieu de spécifier les coordonnées binaires du journal :

CALL mysql.rds_set_external_source_with_auto_position_for_channel(
  'source-endpoint.region.rds.amazonaws.com',
  3306,
  'repl_user',
  'password',
  0,
  0,
  'channel_1'
);

CALL mysql.rds_start_replication_for_channel('channel_1');
Note

Lorsque vous utilisez le positionnement automatique GTID, assurez-vous que les enforce_gtid_consistency paramètres gtid_mode et sont configurés de manière cohérente sur toutes les instances sources et sur le cluster Aurora MySQL.

Répétez ces étapes pour chaque instance de base de données source, en spécifiant un nom de canal unique pour chacune (par exemplechannel_1,channel_2,channel_3).

Utiliser des filtres avec réplication multi-sources

Vous pouvez utiliser des filtres de réplication pour spécifier quelles bases de données et quelles tables sont répliquées sur la réplique multisource Aurora MySQL. Pour plus d'informations sur les filtres de réplication, consultezConfiguration des filtres de réplication avec Aurora MySQL. Ce qui suit décrit les fonctionnalités de filtrage supplémentaires au niveau des canaux disponibles avec la réplication multisource.

Avec la réplication multisource, vous pouvez configurer les filtres de réplication à deux niveaux :

  • Filtres globaux  : s'appliquent à toutes les chaînes. Définissez à l'aide du groupe de paramètres du cluster de bases de données Aurora MySQL (par exemplereplicate-do-db,replicate-ignore-db).

  • Channel-level filtres  : s'applique uniquement à des chaînes spécifiques, en remplaçant les filtres généraux pour cette chaîne.

Comportement clé

  • Vous devez relancer la réplication après avoir modifié les filtres au niveau des canaux.

  • Si aucun filtre spécifique à un canal n'est configuré, Aurora MySQL applique les filtres globaux pour ce canal.

  • Si un filtre est appliqué à la fois globalement et au niveau du canal, seul le filtre au niveau du canal est appliqué pour ce canal.

Surveillez les canaux de réplication multisources

Vous pouvez surveiller des canaux individuels sur une réplique multisource Aurora MySQL à l'aide des méthodes suivantes.

Utilisez SHOW REPLICA STATUS

Connectez-vous à l'instance Writer du cluster de base de données Aurora MySQL et exécutez :

-- View status for all channels
SHOW REPLICA STATUS\G

-- View status for a specific channel
SHOW REPLICA STATUS FOR CHANNEL 'channel_1'\G

Principaux domaines à surveiller :

Champ Description
Replica_IO_Running Si le I/O fil de discussion de la chaîne est en cours d'exécution
Replica_SQL_Running Si le thread SQL du canal est en cours d'exécution
Seconds_Behind_Source Délai de réplication en secondes pour le canal
Last_IO_Error Dernière I/O erreur rencontrée sur la chaîne
Last_SQL_Error Dernière erreur SQL rencontrée sur le canal
Source_Log_File Le fichier journal binaire en cours de lecture depuis la source
Exec_Source_Log_Pos La position dans le journal binaire que le thread SQL a appliquée

Utiliser des CloudWatch métriques

Surveillez la ReplicationChannelLag CloudWatch métrique pour chaque canal de réplication. Cette métrique fournit des données de latence de réplication par canal sur une période de 60 secondes et est disponible pendant 15 jours. Pour localiser le décalage du canal de réplication, utilisez l'identifiant d'instance de cluster de base de données Aurora et le nom du canal de réplication comme dimensions. Vous pouvez configurer CloudWatch des alarmes pour recevoir une notification lorsque le décalage dépasse un seuil spécifique. Pour de plus amples informations, veuillez consulter Surveillance des métriques d’un cluster de bases de données Amazon Aurora.

Gestion des procédures stockées de réplication multi-sources

Pour plus d'informations sur l'utilisation de procédures stockées pour configurer et gérer vos canaux de réplication multisources, consultezGestion de la réplication multisource.

Considérations et pratiques exemplaires

Pour des recommandations générales d'optimisation de la réplication, notamment le format de journal binaire, les outils de travail parallèles et le Binlog amélioré, consultezOptimisation de la réplication des journaux binaires pour Aurora MySQL. Les considérations suivantes sont spécifiques à la réplication multisource.

Planification des ressources

Lors de l'exécution de plusieurs canaux de réplication, le nombre total de fils de réplication alloués à la réplique est le suivant : (replica_parallel_workers+ 1 thread coordinateur) × nombre de canaux. Par exemple, avec la replica_parallel_workers valeur par défaut de 4 et 10 canaux, Aurora MySQL alloue 50 threads de réplication. Envisagez d'utiliser une classe d'instance de base de données plus importante (telle que db.r6g.2xlarge ou supérieure) en fonction de votre débit source total et du nombre de canaux. Chaque canal reçoit le même nombre de travailleurs parallèles. MySQL ne prend pas en charge la définition de différents nombres de travailleurs parallèles par canal.

Éviter les conflits

La réplication multi-sources MySQL ne permet pas de détecter ou de résoudre les conflits. Vous devez vous assurer que les modifications provenant de différentes sources ne sont pas contradictoires. Les stratégies courantes incluent :

  • Chaque source écrit dans une base de données ou un ensemble de tables différent.

  • Utilisez des filtres de réplication (replicate-do-db) pour vous assurer que chaque canal ne réplique que les bases de données dont il est responsable.

  • Utilisez replicate-rewrite-db cette option pour remapper un nom de schéma depuis la source vers un autre nom sur la réplique, si nécessaire.

Pour éviter les conflits d'écriture provenant d'applications se connectant directement à la réplique multisource, activez le mode lecture seule sur le cluster Aurora MySQL : CALL mysql.rds_set_read_only(1);

Meilleures pratiques opérationnelles

  • Un canal à la fois  : effectuez les opérations de gestion (telles que les modifications de configuration, les erreurs de saut ou starting/stopping la réplication) sur un canal à la fois. Évitez de modifier simultanément plusieurs canaux à partir de différentes connexions.

  • Surveiller le décalage par canal  : surveillez le décalage de réplication pour chaque canal à l'aide de la ReplicationChannelLag CloudWatch métrique.

  • Gestion du basculement à la source  : si une instance de base de données source bascule (par exemple, un Multi-AZ basculement Amazon RDS), le canal de réplication peut s'arrêter avec une I/O erreur. Une fois que la source est à nouveau disponible :

    • Appelez mysql.rds_start_replication_for_channel pour reprendre la réplication.

    • Si l'erreur 1236 se produit (fichier journal introuvable), appelez mysql.rds_next_source_log_for_channel pour passer au fichier journal binaire suivant.

  • Basculement de l'enregistreur Aurora  : si l'instance de l'enregistreur Aurora MySQL bascule vers un lecteur, les configurations des canaux de réplication sont préservées sur le stockage partagé du cluster. Une fois le basculement terminé, les threads de réplication sont automatiquement redémarrés sur la nouvelle instance d'écriture.

Limitations

Les limites suivantes sont spécifiques à la réplication multisource Aurora MySQL. Pour les limites générales de la réplication multi-sources MySQL (telles que la configuration de travail parallèle par canal), consultez MySQL Multi-Source Replication dans la documentation MySQL.

  • Multi-source la réplication n'est prise en charge que sur Aurora MySQL version 8.4.8 et supérieure.

  • Aurora MySQL prend en charge la configuration d'un maximum de 15 canaux pour une réplique multisource.

Résolution des problèmes

Pour obtenir des informations générales sur la résolution des problèmes de réplication, consultez Problèmes de réplication Amazon Aurora MySQL. Vous trouverez ci-dessous des notes de dépannage spécifiques à la réplication multisource.

La configuration des canaux n'est pas restaurée après la restauration du snapshot

Les instantanés de clusters de bases de données n'incluent pas les configurations de canaux multisources. Après avoir effectué une restauration à partir d'un instantané :

  • Reconfigurez chaque canal à l'aide de mysql.rds_set_external_source_for_channel oumysql.rds_set_external_source_with_auto_position_for_channel.

  • Si vous utilisez le positionnement automatique GTID, la réplique peut automatiquement reprendre là où elle s'était arrêtée.

  • Si vous utilisez des positions de fichiers journaux binaires, déterminez la position actuelle en comparant le journal binaire de la source à la dernière transaction appliquée sur le cluster restauré.

Le délai de réplication augmente sur un ou plusieurs canaux

  • Vérifiez le processeur et les I/O métriques de l'instance de rédaction. Si l'utilisation des ressources est élevée, augmentez la classe d'instance.

  • Envisagez replica_parallel_workers d'augmenter pour améliorer le débit des threads SQL.

  • Vérifiez qu'aucune transaction de longue durée ou opération DDL sur le canal n'est susceptible de bloquer le thread SQL.

  • Vérifiez l'absence de configurations de filtre conflictuelles susceptibles de provoquer le traitement de la réplication, puis ignorez un grand nombre d'événements.

Exemple : configuration multisource complète avec trois sources

L'exemple suivant montre la configuration d'un cluster de bases de données Aurora MySQL en tant que réplique multisource de trois instances sources RDS pour MySQL.

Étape 1 : enregistrer les positions du journal binaire sur chaque source

Connectez-vous à chaque source et enregistrez les coordonnées du log binaire :

-- On source 1 (orders-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000045, Position: 3892

-- On source 2 (inventory-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000012, Position: 1567

-- On source 3 (analytics-db.xxxxx.us-east-1.rds.amazonaws.com)
SHOW BINARY LOG STATUS;
-- Result: mysql-bin-changelog.000078, Position: 9421

Étape 2 : Importer des données depuis chaque source

# Import from source 1
mysqldump --databases orders_db --single-transaction --compress \
 -u admin -p --host=orders-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

# Import from source 2
mysqldump --databases inventory_db --single-transaction --compress \
 -u admin -p --host=inventory-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

# Import from source 3
mysqldump --databases analytics_db --single-transaction --compress \
 -u admin -p --host=analytics-db.xxxxx.us-east-1.rds.amazonaws.com | \
 mysql --host=my-aurora-cluster.cluster-xxxxx.us-east-1.rds.amazonaws.com -u admin -p

Étape 3 : Configuration et démarrage des canaux de réplication

Connectez-vous à l'instance Aurora MySQL Writer :

-- Configure channel for source 1 (orders)
CALL mysql.rds_set_external_source_for_channel(
 'orders-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000045', 3892, 0, 'orders_channel'
);

-- Configure channel for source 2 (inventory)
CALL mysql.rds_set_external_source_for_channel(
 'inventory-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000012', 1567, 0, 'inventory_channel'
);

-- Configure channel for source 3 (analytics)
CALL mysql.rds_set_external_source_for_channel(
 'analytics-db.xxxxx.us-east-1.rds.amazonaws.com',
 3306, 'repl_user', 'password',
 'mysql-bin-changelog.000078', 9421, 0, 'analytics_channel'
);

-- Start all channels
CALL mysql.rds_start_replication_for_channel('orders_channel');
CALL mysql.rds_start_replication_for_channel('inventory_channel');
CALL mysql.rds_start_replication_for_channel('analytics_channel');

Étape 4 : vérifier l'état de la réplication

SHOW REPLICA STATUS\G

Vérifiez que pour chaque canal :

  • Replica_IO_Running: Yes

  • Replica_SQL_Running: Yes

  • Seconds_Behind_Source: 0(ou une valeur faible)

Ressources connexes