Data Transmission Service:Synchroniser des données d'une instance ApsaraDB RDS for MySQL vers un projet MaxCompute

Exigences relatives à la base de données source

• Les tables doivent posséder une contrainte PRIMARY KEY ou UNIQUE garantissant l'unicité de tous les champs. Sans cette contrainte, la destination risque de contenir des enregistrements en double.

• Lors de la synchronisation de tables impliquant un renommage de colonnes ou de tables, une seule tâche prend en charge jusqu'à 1 000 tables. Si vous exécutez une tâche synchronisant plus de 1 000 tables, une erreur de requête se produit. Utilisez plusieurs tâches ou effectuez la synchronisation au niveau de la base de données.

• N'exécutez pas d'instructions LDD pendant la synchronisation du schéma ou la synchronisation complète des données, sous peine d'échec de la tâche.

• Les données générées par des opérations en cascade ou par la restauration d'une sauvegarde physique ne sont pas synchronisées.

• Si la source exécute MySQL 8.0.23 ou une version ultérieure et que les tables contiennent des colonnes invisibles, ces colonnes sont exclues, ce qui entraîne une perte de données. Exécutez l'instruction ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; pour les rendre visibles avant de démarrer la tâche. Les tables sans clé primaire reçoivent automatiquement des clés primaires invisibles ; rendez-les également visibles. Consultez les pages Invisible Columns et Generated Invisible Primary Keys.

Exigences relatives au journal binaire

Configurez les paramètres MySQL suivants avant de créer la tâche :

Exigences de rétention des journaux binaires :

• ApsaraDB RDS for MySQL : conservez les journaux binaires pendant au moins 3 jours ; 7 jours sont recommandés.

• MySQL autogéré : conservez les journaux binaires pendant au moins 7 jours.

Si les journaux binaires sont purgés avant que DTS ne puisse les lire, la tâche échoue et des incohérences ou pertes de données peuvent survenir. Consultez la page Supprimer les fichiers de journal binaire pour savoir comment définir la période de rétention.

Autres limitations

• Effectuez la synchronisation pendant les heures creuses. La synchronisation complète des données utilise les ressources en lecture et en écriture de la source et de la destination, ce qui augmente la charge du serveur.

• Une fois la synchronisation complète des données terminée, l'espace de table de la destination est plus volumineux que celui de la source en raison de la fragmentation causée par les opérations INSERT concurrentes.

• N'exécutez pas l'outil pt-online-schema-change ni d'autres outils LDD en ligne similaires sur les objets synchronisés pendant l'exécution de la tâche, sous peine d'échec.

• L'écriture de données provenant d'autres sources dans la destination pendant la synchronisation peut provoquer des incohérences de données.

• Si EncDB est activé sur la source, la synchronisation complète des données n'est pas prise en charge. Le chiffrement transparent des données (TDE) n'est pas soumis à cette restriction : les instances TDE prennent en charge la synchronisation du schéma, complète et incrémentielle.

• En cas d'échec d'une tâche DTS, l'assistance technique DTS tente de la restaurer dans un délai de 8 heures. Pendant cette période, la tâche peut être redémarrée et ses paramètres (et non ceux de la base de données) peuvent être modifiés.

Cas particuliers pour MySQL autogéré

• Un basculement principal/secondaire pendant l'exécution de la tâche provoque son échec.

• La latence de synchronisation est calculée à partir de l'horodatage des dernières données synchronisées dans la destination par rapport à l'horodatage actuel de la source. Si aucune opération LMD n'est exécutée sur la source pendant une période prolongée, la latence affichée peut être inexacte. Pour l'actualiser, exécutez n'importe quelle opération LMD sur la source. Si vous synchronisez une base de données entière, créez une table de heartbeat qui reçoit des mises à jour chaque seconde.

• DTS exécute périodiquement l'instruction CREATE DATABASE IF NOT EXISTS 'test' sur la source pour faire avancer la position du journal binaire.

Cas particuliers pour ApsaraDB RDS for MySQL

• Les instances ApsaraDB RDS for MySQL 5.6 en lecture seule qui n'enregistrent pas les journaux de transactions ne peuvent pas servir de source.

• DTS exécute périodiquement l'instruction CREATE DATABASE IF NOT EXISTS 'test' sur la source pour faire avancer la position du journal binaire.

Étape 1 : Ouvrir la page Synchronisation des données

Utilisez l'une des consoles suivantes pour accéder à la page de configuration de la tâche.

Console DTS

1. Connectez-vous à la console DTS.

2. Dans le volet de navigation de gauche, cliquez sur Data Synchronization.

3. Dans le coin supérieur gauche, sélectionnez la région où résidera l'instance de synchronisation.

Console DMS

Le chemin de navigation exact dépend du mode et de la disposition de votre console DMS. Consultez les pages Mode simple et Personnaliser la disposition et le style de la console DMS .

1. Connectez-vous à la console DMS.

2. Dans la barre de navigation supérieure, placez le pointeur sur Data + AI et choisissez DTS (DTS) > Data Synchronization.

3. Dans la liste déroulante à droite de Data Synchronization Tasks, sélectionnez la région.

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

Cliquez sur Create Task, puis configurez les paramètres suivants.

Étape 3 : Tester la connectivité

Cliquez sur Test Connectivity and Proceed en bas de la page.

DTS nécessite un accès aux deux bases de données. Si vous vous connectez à une base de données autogérée, les blocs CIDR de DTS doivent être ajoutés à ses paramètres de sécurité. Consultez la page Ajouter les blocs CIDR des serveurs DTS . Pour les bases de données autogérées n'utilisant pas l'accès Alibaba Cloud Instance , cliquez sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers .

Cliquez sur OK pour accorder des autorisations à votre compte MaxCompute, puis cliquez sur Test Connectivity and Proceed.

Étape 4 : Configurer les objets

À l'étape Configure Objects, définissez les paramètres suivants.

Le renommage d'un objet via le mappage de nom d'objet peut entraîner l'échec de la synchronisation des objets dépendants.

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

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

Étape 6 : Exécuter la prévérification

Cliquez sur Next: Save Task Settings and Precheck.

Pour prévisualiser les paramètres API de cette configuration de tâche, survolez le bouton et cliquez sur Preview OpenAPI parameters avant de poursuivre.

DTS exécute une prévérification avant le démarrage de la tâche.

• Si un élément échoue, cliquez sur View Details pour en connaître la cause. Corrigez le problème, puis cliquez sur Precheck Again.

• Si un élément déclenche une alerte ignorables, cliquez sur Confirm Alert Details, puis sur Ignore dans la boîte de dialogue, et enfin sur OK. Cliquez sur Precheck Again pour continuer. Ignorer les alertes peut entraîner des incohérences de données.

Étape 7 : Acheter et démarrer l'instance

1. Attendez que le Success Rate atteigne 100 %, puis cliquez sur Next: Purchase Instance.

2. Sur la page d'achat, configurez les paramètres suivants.

1. Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.

2. Cliquez sur Buy and Start. Dans la boîte de dialogue de confirmation, cliquez sur OK.

La tâche apparaît dans la liste des tâches. Vous pouvez y surveiller sa progression.

set odps.sql.allow.fullscan=true;