Data Transmission Service:Synchronisation unidirectionnelle entre des instances RDS MySQL

Structure de table

• Les tables à synchroniser doivent disposer d'une contrainte PRIMARY KEY ou UNIQUE incluant tous les champs uniques. Sans cela, la destination peut contenir des enregistrements en double.

• Si vous sélectionnez des tables (et non des bases de données) comme objets de synchronisation et prévoyez de renommer des tables ou des colonnes, une seule tâche prend en charge jusqu'à 1 000 tables. Pour plus de 1 000 tables, configurez plusieurs tâches ou effectuez la synchronisation au niveau de la base de données.

Journal binaire

Configurez les paramètres de journal binaire suivants avant que DTS puisse lire les modifications depuis la source :

• Définissez binlog_row_image sur full. La journalisation binaire est activée par défaut sur les instances ApsaraDB RDS for MySQL, mais vérifiez ce paramètre. Consultez Modifier les paramètres de l'instance.

  • Si la source est une base de données MySQL gérée par vos soins : activez la journalisation binaire et définissez binlog_format sur row et binlog_row_image sur full.

  • Si la source est une base de données MySQL gérée par vos soins déployée dans un cluster à deux nœuds principaux : définissez également log_slave_updates sur ON pour vous assurer que DTS peut obtenir tous les journaux binaires. Consultez Créer un compte pour une base de données MySQL gérée par vos soins et configurer la journalisation binaire.

• La rétention des journaux binaires doit être d'au moins 7 jours. Si DTS ne peut pas accéder aux journaux binaires requis, la tâche échoue et une perte de données peut survenir. Consultez Gérer les fichiers de journal binaire.

N'exécutez pas d'instructions DDL sur la base de données source pendant la synchronisation du schéma ou la synchronisation complète des données. Cela entraînerait l'échec de la tâche.

Compatibilité des versions et des jeux de caractères

• La version de la base de données de destination doit être identique ou supérieure à celle de la source. Une version de destination plus ancienne peut entraîner des problèmes de compatibilité.

• Si la base de données source est MySQL 8.0.23 ou ultérieure et contient des colonnes invisibles, DTS ne peut pas récupérer les données de ces colonnes, ce qui entraîne une perte de données.

• Si la base de données de destination est MySQL 8.0.23 ou ultérieure et contient des colonnes invisibles, les colonnes de destination destinées à recevoir les données sont introuvables, ce qui provoque l'échec de l'instance DTS et une perte de données.

• Dans les deux cas, exécutez ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; pour rendre les colonnes invisibles visibles avant de démarrer la tâche. Les tables sans clés primaires génèrent automatiquement des clés primaires invisibles ; rendez-les également visibles. Consultez Colonnes invisibles et Clés primaires invisibles générées.

• Si vous n'utilisez pas la synchronisation du schéma, assurez-vous que la compatibilité des types de champs est maintenue. Par exemple, un champ text dans la source mappé à un champ varchar(255) dans la destination peut entraîner une troncature des données.

• Si les données contiennent des caractères sur 4 octets (tels que des caractères rares ou des emojis), les tables de destination doivent utiliser le jeu de caractères UTF8mb4. Si vous utilisez la synchronisation du schéma, définissez le paramètre character_set_server sur UTF8mb4 dans la base de données de destination.

• Les noms de colonnes dans MySQL ne sont pas sensibles à la casse. Si la source comporte plusieurs colonnes dont les noms ne diffèrent que par la casse, elles sont écrites dans la même colonne de la destination, ce qui entraîne des résultats inattendus.

DDL en ligne

• N'utilisez pas pt-online-schema-change pour les opérations DDL en ligne sur les tables sélectionnées comme objets de synchronisation. Utilisez plutôt Data Management (DMS). Consultez Effectuer des opérations DDL sans verrou.

• Si les opérations DDL échouent dans la destination, la tâche DTS continue de s'exécuter. Vérifiez les journaux de la tâche pour identifier les instructions DDL ayant échoué. Consultez Afficher les journaux de la tâche.

• DTS ne synchronise pas les données utilisant des analyseurs définis par des commentaires.

Cohérence des données

• N'écrivez pas de données provenant d'autres sources dans la destination pendant la synchronisation. Cela entraînerait une incohérence des données.

• Les données générées par les opérations de changement de journal binaire (telles que les données restaurées à partir d'une sauvegarde physique ou des opérations en cascade) ne sont pas enregistrées ni synchronisées vers la destination pendant l'exécution de la tâche.

Comportement des clés étrangères

• Pendant la synchronisation du schéma, DTS synchronise les clés étrangères de la source vers la destination.

• Pendant la synchronisation complète et incrémentielle des données, DTS désactive temporairement les vérifications de contraintes de clés étrangères et les opérations en cascade au niveau de la session. Les opérations de mise à jour ou de suppression en cascade sur la source durant cette période peuvent entraîner une incohérence des données.

Impact sur les performances

La synchronisation complète des données lit toutes les données de la base de données source une fois, ce qui augmente la charge sur les deux bases de données. Pour réduire les risques :

• Exécutez les tâches de synchronisation pendant les heures creuses.

• Attendez-vous à ce que l'espace table de la destination soit plus grand que celui de la source après la synchronisation complète, en raison de la fragmentation des insertions concurrentes.

• Une fois que l'état de la tâche passe à Completed, exécutez analyze table <table_name> pour vérifier que les données ont été correctement écrites dans la destination. (Par exemple, un basculement de haute disponibilité (HA) dans la source peut entraîner l'écriture de certaines données uniquement en mémoire.)

Cas particuliers

Pour les sources MySQL gérées par vos soins :

• Si un basculement principal/secondaire se produit sur la base de données source pendant l'exécution de la tâche, la tâche échoue.

• DTS calcule la latence de synchronisation en fonction de l'horodatage des dernières données synchronisées dans la destination et de l'horodatage actuel dans la source. Si aucune opération DML n'est effectuée sur la source pendant une longue période, la latence peut être inexacte. Si la latence est trop élevée, effectuez une opération DML sur la source pour la mettre à jour. Si vous sélectionnez une base de données entière comme objet de synchronisation, vous pouvez créer une table de heartbeat mise à jour chaque seconde pour maintenir la précision de la latence.

• DTS exécute CREATE DATABASE IF NOT EXISTS 'test' dans la source selon une planification afin de faire avancer la position du journal binaire.

Pour les sources ApsaraDB RDS for MySQL :

• Les instances ApsaraDB RDS for MySQL 5.6 en lecture seule (qui n'enregistrent pas les journaux de transaction) ne peuvent pas être utilisées comme source.

• DTS exécute CREATE DATABASE IF NOT EXISTS 'test' dans la source selon une planification afin de faire avancer la position du journal binaire.

• Les instances ApsaraDB RDS for MySQL avec la fonctionnalité EncDB activée ne prennent pas en charge la synchronisation complète des données. Les instances avec Transparent Data Encryption (TDE) activé prennent en charge la synchronisation du schéma, la synchronisation complète des données et la synchronisation incrémentielle des données.

Si le support technique DTS restaure une tâche ayant échoué :

• Le support tente une restauration dans un délai de 8 heures. La tâche peut être redémarrée et certains paramètres de tâche peuvent être modifiés. Les paramètres de base de données ne sont pas modifiés.

Étape 1 : Accéder à la page des tâches de synchronisation des données

1. Connectez-vous à la console Data Management (DMS).

2. Dans la barre de navigation supérieure, cliquez sur Data + AI.

3. Dans le volet de navigation de gauche, choisissez DTS (DTS) > Data Synchronization.

La navigation peut varier selon le mode et la disposition de votre console DMS. Consultez Mode simple et Personnaliser la disposition et le style de la console DMS . Sinon, accédez directement à la page des tâches de synchronisation des données de la nouvelle console DTS .

Étape 2 : Créer la tâche

1. Sélectionnez la région où réside votre instance de synchronisation des données.

   Dans la nouvelle console DTS, sélectionnez plutôt la région dans la barre de navigation supérieure.

2. Cliquez sur Create Task.

3. (Facultatif) Cliquez sur New Configuration Page dans le coin supérieur droit de la page.

   Ignorez cette étape si le bouton Back to Previous Version est affiché. La nouvelle page de configuration est recommandée.

Étape 3 : Configurer les bases de données source et de destination

Remplissez les paramètres suivants pour la source et la destination :

Étape 4 : Tester la connectivité

Cliquez sur Test Connectivity and Proceed.

DTS ajoute automatiquement ses blocs CIDR de serveur à la liste d'autorisation des instances de base de données Alibaba Cloud. Pour les bases de données hébergées sur ECS, DTS ajoute les blocs CIDR aux règles du groupe de sécurité ECS et vous devez vous assurer que l'instance ECS peut accéder à la base de données — si la base de données s'étend sur plusieurs instances ECS, ajoutez manuellement les blocs CIDR au groupe de sécurité de chaque instance. Pour les bases de données locales ou hébergées par des fournisseurs cloud tiers, ajoutez manuellement les blocs CIDR des serveurs DTS à la liste d'autorisation de la base de données. Consultez Blocs CIDR des serveurs DTS.

Étape 5 : Configurer les objets de synchronisation

À l'étape Configure Objects, remplissez les paramètres suivants :

Le renommage d'un objet avec le mappage des noms d'objets peut empêcher la synchronisation d'autres objets qui en dépendent.

Étape 6 : Configurer les paramètres avancés

Cliquez sur Next: Advanced Settings et remplissez les paramètres suivants :

Étape 7 : Configurer la vérification des données (facultatif)

Cliquez sur Next Step: Data Verification pour configurer la vérification des données pour la tâche. Consultez Configurer une tâche de vérification des données.

Étape 8 : Exécuter la pré-vérification

Cliquez sur Next: Save Task Settings and Precheck.

Pour prévisualiser les paramètres d'API pour cette configuration, survolez Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters .

DTS exécute une pré-vérification avant que la tâche ne puisse démarrer. Attendez que la pré-vérification soit terminée :

• Si un élément échoue, cliquez sur View Details pour voir la cause et corriger le problème, puis cliquez sur Precheck Again.

• Si un élément affiche une alerte, corrigez le problème ou cliquez sur Confirm Alert Details > Ignore > OK > Precheck Again pour continuer. Ignorer les alertes peut entraîner une incohérence des données.

Étape 9 : Acheter l'instance

Une fois que le Success Rate atteint 100 %, cliquez sur Next: Purchase Instance.

Sur la page buy, configurez les éléments suivants :

Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms, puis cliquez sur Buy and Start et confirmez.

La tâche apparaît dans la liste des tâches. Surveillez sa progression à cet endroit.