Synchronize data from TiDB to AnalyticDB for MySQL 3.0 - Data Transmission Service

Fonctionnement

DTS lit les modifications incrémentielles depuis TiDB via un cluster Kafka qui sert de tampon pour la capture des données modifiées (CDC), puis écrit les données dans AnalyticDB for MySQL V3.0. Le pipeline complet est le suivant :

TiDB → Cluster Kafka → DTS → AnalyticDB for MySQL V3.0

TiDB n’expose pas directement les journaux binaires à DTS. Vous devez installer l’un des composants CDC suivants pour publier les modifications incrémentielles dans une rubrique Kafka :

TiDB Binlog — utilise les composants Pump et Drainer
TiCDC — utilise le format Canal-JSON

DTS lit les données depuis la partition 0 de la rubrique Kafka et applique les modifications au cluster de destination.

Limites

Passez en revue ces limites avant de configurer la tâche.

Limites de la base de données source

Limite	Détails
Clé primaire ou contrainte unique requise	Les tables à synchroniser doivent disposer d’une PRIMARY KEY ou d’une contrainte UNIQUE incluant tous les champs uniques. Les tables dépourvues de cette contrainte peuvent générer des enregistrements en double dans la destination.
Restrictions DDL pendant la synchronisation	N’exécutez pas d’instructions DDL modifiant les schémas de base de données ou de tables pendant la synchronisation du schéma ou la synchronisation complète des données. La tâche échouerait.
Perte de la longueur d’index de préfixe	TiDB ne stocke pas la longueur des index de préfixe dans les métadonnées. Cette longueur est perdue lors de la synchronisation des données vers AnalyticDB for MySQL V3.0, ce qui peut entraîner un échec de l’instance de destination. Corrigez manuellement les longueurs d’index de préfixe pour toutes les tables qui en utilisent.
Limite de tables par tâche	Si vous sélectionnez des tables individuelles (et non des bases de données entières) et que vous les renommez, une tâche prend en charge jusqu’à 1 000 tables. Si vous dépassez cette limite, configurez plusieurs tâches ou synchronisez des bases de données entières.
Configuration Kafka requise	Déployez un cluster Kafka et installez TiDB Binlog ou TiCDC avant de créer la tâche DTS.
Bande passante sortante	Le serveur hébergeant TiDB doit disposer d’une bande passante sortante suffisante. Une bande passante insuffisante réduit la vitesse de synchronisation.

Limites de la destination et de la tâche

Limite	Détails
Partition Kafka	DTS lit uniquement depuis la partition 0 de la rubrique Kafka. Créez la rubrique avec exactement une partition.
Clé primaire personnalisée requise	Spécifiez une clé primaire personnalisée dans AnalyticDB for MySQL V3.0, ou configurez Primary Key Column à l’étape Configurations for Databases, Tables, and Columns. À défaut, la tâche pourrait échouer.
Seuil d’utilisation du disque	Si l’utilisation du disque sur n’importe quel nœud du cluster AnalyticDB for MySQL V3.0 dépasse 80 %, la tâche DTS subit un retard et renvoie des erreurs. Estimez l’espace disque requis avant de commencer.
Conflits de sauvegarde	Si le cluster de destination fait l’objet d’une sauvegarde pendant l’exécution de DTS, la tâche échoue.
Types de données hétérogènes	Les types de données de TiDB et d’AnalyticDB for MySQL V3.0 ne correspondent pas un à un. Consultez la section Mappages de types de données pour la synchronisation initiale du schéma pour plus de détails.
Précision FLOAT/DOUBLE	DTS utilise `ROUND(COLUMN,PRECISION)` pour récupérer les valeurs FLOAT et DOUBLE. La précision par défaut est de 38 chiffres pour FLOAT et de 308 chiffres pour DOUBLE. Vérifiez que ces valeurs par défaut répondent à vos besoins.
Vues matérialisées non prises en charge	Pendant la synchronisation du schéma, DTS ne prend pas en charge la synchronisation des vues matérialisées vers l’instance AnalyticDB for MySQL de destination. Pour utiliser des vues matérialisées, créez-les manuellement dans l’instance de destination une fois la synchronisation terminée.
Initialisation du décalage de la tâche	Après la création de la tâche, effectuez rapidement des opérations sur la base de données source ou insérez des données de test. Cela met à jour le décalage de la tâche. Si vous ignorez cette étape, la tâche risque d’échouer en raison d’une latence excessive.
Données provenant d’autres sources	N’écrivez pas de données dans le cluster de destination depuis d’autres sources pendant la synchronisation. Cela entraînerait une incohérence des données.
Reprise d’une tâche ayant échoué	DTS relance automatiquement les tâches ayant échoué pendant une durée maximale de 7 jours. Avant de basculer les charges de travail vers le cluster de destination, arrêtez ou libérez toutes les tâches ayant échoué. Vous pouvez également exécuter `REVOKE` pour supprimer les autorisations d’écriture de DTS de la base de données de destination, afin qu’une tâche reprise ne puisse pas écraser les nouvelles données.
Performances de la synchronisation complète des données	La synchronisation complète des données augmente la charge sur les bases de données source et de destination. Exécutez-la pendant les heures creuses, lorsque l’utilisation du CPU est inférieure à 30 %.
Taille de l’espace table après la synchronisation complète	Les opérations INSERT concurrentes pendant la synchronisation complète des données provoquent une fragmentation des tables. L’espace table de destination sera plus grand que celui de la source.
Échecs DDL	Si une instruction DDL échoue dans la base de données de destination, la tâche se poursuit. Consultez les journaux de la tâche pour afficher les instructions DDL ayant échoué.
SLA du support technique DTS	Si une tâche DTS ne parvient pas à s’exécuter, le support technique DTS tentera de restaurer la tâche sous 8 heures. Lors de la restauration, la tâche peut être redémarrée et ses paramètres modifiés. Seuls les paramètres de la tâche peuvent être modifiés ; les paramètres de la base de données restent inchangés.

Remarque

Si la destination est un cluster AnalyticDB for MySQL, DTS prend uniquement en charge l’écriture de types de données nativement pris en charge par AnalyticDB for MySQL. Cela inclut les types de données de base et les types de données complexes tels que ARRAY, MAP et JSON. Les types de données comme MULTIVALUE ne sont pas pris en charge.

Opérations SQL pour la synchronisation incrémentielle

Type d’opération	Instructions prises en charge
DML	INSERT, UPDATE, DELETE
DDL	CREATE TABLE, DROP TABLE, RENAME TABLE, TRUNCATE TABLE, ADD COLUMN, DROP COLUMN

Lorsque DTS écrit des instructions UPDATE dans AnalyticDB for MySQL V3.0, il les convertit automatiquement en REPLACE INTO . Si l’instruction UPDATE affecte la clé primaire, DTS la convertit en DELETE suivi d’un INSERT.

Facturation

Type de synchronisation	Coût
Synchronisation du schéma et synchronisation complète des données	Gratuit
Synchronisation incrémentielle des données	Payant. Consultez la section Présentation de la facturation.

Prérequis

Avant de commencer, assurez-vous d’avoir :

Un cluster AnalyticDB for MySQL V3.0 dont l’espace de stockage disponible est supérieur à la taille totale des données de votre base de données TiDB. Consultez la section Créer un cluster
Un cluster Kafka ou une instance ApsaraMQ for Kafka déployée et accessible depuis le serveur TiDB
Les autorisations de compte de base de données requises (consultez la section Autorisations requises)

Autorisations requises

Base de données	Autorisations requises	Référence
TiDB	SELECT sur les objets à synchroniser, SHOW VIEW	Gestion des privilèges
AnalyticDB for MySQL V3.0	Autorisations de lecture et d’écriture sur la base de données de destination	Créer un compte de base de données

Configurer la capture des données incrémentielles

DTS nécessite que les événements de modification incrémentiels de TiDB soient publiés dans une rubrique Kafka. Choisissez l’une des méthodes suivantes.

Choisir une méthode

	TiDB Binlog	TiCDC
Composants	Pump + Drainer	TiCDC (géré via TiUP)
Format de sortie	Format binlog TiDB par défaut	Format Canal-JSON
Idéal pour	Déploiements TiDB Binlog existants	Nouvelles installations et TiDB v4.0+
Paramètre DTS	Utiliser le format binlog par défaut de la base de données TiDB	Utiliser le format Canal-JSON de TiCDC

Préparer le cluster Kafka

Les deux méthodes nécessitent un cluster Kafka. Utilisez l’une des options suivantes :

Cluster Kafka auto-géré : déployez Apache Kafka. Consultez la documentation Apache Kafka
Instance ApsaraMQ for Kafka : créez une instance. Consultez la section Présentation de la prise en main

Quelle que soit l’option choisie :

Déployez le cluster Kafka dans le même réseau ou cloud privé virtuel (VPC) que le serveur TiDB afin de minimiser la latence réseau.
Définissez les paramètres du broker Kafka message.max.bytes et replica.fetch.max.bytes sur des valeurs élevées, et définissez le paramètre du consommateur fetch.message.max.bytes sur une valeur élevée correspondante. Cela garantit que le cluster peut gérer le volume de données de journal binaire provenant de TiDB. Consultez la section Référence de configuration Kafka.

Après avoir configuré le cluster, créez une rubrique avec exactly one partition. DTS lit uniquement depuis la partition 0 ; plusieurs partitions entraîneraient une perte de données.

Option 1 : TiDB Binlog

Déployez Pump et Drainer sur des serveurs situés dans le même réseau interne que TiDB. Consultez la section Déploiement du cluster TiDB Binlog.
Modifiez le fichier de configuration de Drainer pour pointer vers votre cluster Kafka en tant que récepteur aval. Consultez le guide utilisateur Binlog Consumer Client. Vérifiez que le serveur TiDB peut se connecter au cluster Kafka avant de continuer.
Ajoutez les blocs CIDR des serveurs DTS à la liste d’autorisation de la base de données TiDB. Consultez la section Ajouter les blocs CIDR des serveurs DTS.

Option 2 : TiCDC

Installez TiCDC à l’aide de TiUP. Ajoutez un nouveau nœud TiCDC ou étendez un nœud existant dans le cluster TiDB. Consultez la section Déployer et maintenir TiCDC.
Créez un flux de modifications (changefeed) pour répliquer les données incrémentielles de TiDB vers votre cluster Kafka. Utilisez tiup cdc cli changefeed create et spécifiez l’URI du récepteur Canal-JSON. Consultez les sections Répliquer des données vers Kafka. Vérifiez que le serveur TiDB peut se connecter au cluster Kafka avant de continuer.

Créer une tâche de synchronisation des données

Étape 1 : Accéder à la page Synchronisation des données

Utilisez la console DTS ou la console DMS.

Console DTS

Connectez-vous à la console DTS.Console DTS
Dans le volet de navigation de gauche, cliquez sur Data Synchronization.
Dans le coin supérieur gauche, sélectionnez la région où résidera l’instance de synchronisation.

Console DMS

Les étapes peuvent varier selon la disposition de la console DMS. Consultez les sections Mode simple et Personnaliser la disposition et le style de la console DMS .

Connectez-vous à la console DMS.Console DMS
Dans la barre de navigation supérieure, placez le pointeur sur Data + AI et choisissez DTS (DTS) > Data Synchronization.
Dans la liste déroulante située à droite de Data Synchronization Tasks, sélectionnez la région où résidera l’instance de synchronisation.

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

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

Base de données source

Paramètre	Description
Task Name	Nom de la tâche DTS. DTS en génère un automatiquement. Spécifiez un nom descriptif pour une identification facile. Le nom n’a pas besoin d’être unique.
Select a DMS database instance	Sélectionnez une base de données enregistrée existante, ou laissez ce champ vide et remplissez les paramètres ci-dessous. Pour enregistrer une base de données : dans la console DMS, cliquez sur Add DMS Database Instance ; dans la console DTS, utilisez la page Database Connections. Consultez les sections Enregistrer une instance de base de données Alibaba Cloud et Enregistrer une base de données hébergée sur un service cloud tiers ou une base de données auto-gérée.
Database Type	Sélectionnez TiDB.
Access Method	Sélectionnez la méthode d’accès correspondant à l’emplacement de déploiement de TiDB. Cet exemple utilise Self-managed Database on ECS. Pour les autres méthodes d’accès, préparez d’abord l’environnement requis. Consultez la section Présentation de la préparation.
Instance Region	Région où réside TiDB.
ECS Instance ID	ID de l’instance ECS hébergeant TiDB.
Port Number	Port du service TiDB. Par défaut : 4000.
Database Account	Compte TiDB disposant des autorisations requises.
Database Password	Mot de passe du compte TiDB.
Migrate Incremental Data	Toujours défini sur Yes paramètres de notification d’alerte. Ce paramètre ne peut pas être modifié. Pour synchroniser sans données incrémentielles, créez plutôt une tâche de migration de données. Consultez la section Migrer des données d’une base de données TiDB auto-gérée vers un cluster AnalyticDB for MySQL V3.0.
Kafka Cluster Type	Sélectionnez la méthode d’accès correspondant à l’emplacement de déploiement de votre cluster Kafka. Cet exemple utilise Self-managed Database on ECS. Si vous sélectionnez Express Connect, VPN Gateway, or Smart Access Gateway, sélectionnez également un VPC dans Connected VPC et spécifiez Domain Name or IP.
Kafka Data Source Component	Sélectionnez Use the default binlog format of the TiDB database (pour TiDB Binlog) ou Use the TiCDC Canal-JSON format (pour TiCDC), selon la configuration effectuée dans la section Configurer la capture des données incrémentielles.
ECS Instance ID	ID de l’instance ECS sur laquelle le cluster Kafka est déployé.
Port Number	Port du service Kafka.
Kafka Cluster Account / Kafka Cluster Password	Nom d’utilisateur et mot de passe Kafka. Laissez vide si l’authentification n’est pas activée.
Kafka Version	Version de Kafka. Si la version est 1,0 ou ultérieure, sélectionnez 1.0.
Encryption	Sélectionnez Non-encrypted ou SCRAM-SHA-256 selon vos exigences de sécurité.
Topic	Rubrique Kafka qui reçoit les données incrémentielles de TiDB.

Base de données de destination

Paramètre	Description
Select a DMS database instance	Sélectionnez une base de données enregistrée existante, ou laissez ce champ vide et remplissez les paramètres ci-dessous.
Database Type	Sélectionnez AnalyticDB for MySQL 3.0.
Access Method	Sélectionnez Alibaba Cloud Instance.
Instance Region	Région où réside le cluster AnalyticDB for MySQL V3.0.
Instance ID	ID du cluster AnalyticDB for MySQL V3.0 de destination.
Database Account	Compte de base de données disposant des autorisations de lecture et d’écriture.
Database Password	Mot de passe du compte de base de données.

Étape 3 : Tester la connectivité

Cliquez sur Test Connectivity and Proceed. Dans la boîte de dialogue CIDR Blocks of DTS Servers, cliquez sur Test Connectivity.

Si les blocs CIDR de DTS ne sont pas déjà ajoutés aux paramètres de sécurité de votre base de données, ajoutez-les avant de continuer. Consultez la section Ajouter les blocs CIDR des serveurs DTS.

Étape 4 : Configurer les objets à synchroniser

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

Paramètre	Description
Synchronization Types	Sélectionnez Schema Synchronization, Full Data Synchronization et Incremental Data Synchronization. Les trois sont requis. Incremental Data Synchronization est sélectionné par défaut ; vous devez également sélectionner les deux autres. La synchronisation complète des données fournit la base historique des données pour la synchronisation incrémentielle.
Processing Mode of Conflicting Tables	Precheck and Report Errors (par défaut) : échoue à la vérification préalable si des tables portant des noms identiques existent dans la destination. Utilisez le mappage de noms d’objets pour résoudre les conflits sans supprimer les tables de destination. Consultez la section Mapper les noms d’objets. Ignore Errors and Proceed : ignore la vérification préalable pour les noms de tables identiques. Pendant la synchronisation complète, les enregistrements de destination existants sont conservés. Pendant la synchronisation incrémentielle, les enregistrements de destination sont écrasés. Utilisez cette option avec prudence, car elle peut entraîner une incohérence des données.
Capitalization of Object Names in Destination Instance	Contrôle la casse des noms de bases de données, de tables et de colonnes dans la destination. Par défaut : DTS default policy. Consultez la section Spécifier la casse des noms d’objets dans l’instance de destination.
Source Objects	Sélectionnez les bases de données ou les tables à synchroniser et cliquez sur l’icône de flèche pour les déplacer vers Selected Objects.
Selected Objects	Pour renommer un objet dans la destination, faites un clic droit dessus et utilisez le mappage de noms d’objets. Pour renommer plusieurs objets à la fois, cliquez sur Batch Edit. Pour filtrer les lignes avec des conditions WHERE SQL, faites un clic droit sur une table et spécifiez les conditions. Consultez la section Spécifier les conditions de filtrage. Le renommage d’un objet peut rompre les objets dépendants.

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

Cliquez sur Next: Advanced Settings et configurez les éléments suivants.

Paramètre	Description

|

Dedicated Cluster for Task Scheduling

|

Par défaut, DTS planifie les tâches sur un cluster partagé et vous n’avez pas besoin de sélectionner un cluster. Pour des performances plus stables, vous pouvez acheter un cluster dédié pour exécuter les tâches de synchronisation DTS. Pour plus d’informations, consultez la section Qu’est-ce qu’un cluster dédié DTS ?.

|

Retry Time for Failed Connections	Durée pendant laquelle DTS relance les connexions échouées après le démarrage de la tâche. Plage : 10–1440 minutes. Par défaut : 720 minutes. Définissez une valeur supérieure à 30 minutes. Si plusieurs tâches partagent la même base de données source ou de destination, le délai de nouvelle tentative le plus court est prioritaire.
Retry Time for Other Issues	Durée pendant laquelle DTS relance les opérations DDL ou DML ayant échoué. Plage : 1–1440 minutes. Par défaut : 10 minutes. Définissez une valeur supérieure à 10 minutes. Cette valeur doit être inférieure au Retry Time for Failed Connections.
Enable Throttling for Full Data Synchronization	Limite la charge de lecture et d’écriture pendant la synchronisation complète des données. Configurez QPS (queries per second) to the source database, RPS of Full Data Migration et Data migration speed for full migration (MB/s). Disponible uniquement lorsque Full Data Synchronization est sélectionné.
Enable Throttling for Incremental Data Synchronization	Limite la charge d’écriture pendant la synchronisation incrémentielle des données. Configurez RPS of Incremental Data Synchronization et Data synchronization speed for incremental synchronization (MB/s).
Environment Tag	Balise facultative permettant d’identifier l’instance DTS par environnement (par exemple, production ou test).
Configure ETL	Sélectionnez Yes pour activer l’extraction, la transformation et le chargement (ETL) et saisir les instructions de traitement des données. Sélectionnez No pour ignorer. Consultez la section Qu’est-ce que l’ETL ?
Monitoring and Alerting	Sélectionnez Yes pour configurer des alertes en cas d’échec de la tâche ou de dépassement du seuil de latence. Configurez le seuil d’alerte et les paramètres de notification. Consultez la section Configurer la surveillance et les alertes.

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

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

Étape 7 : Configurer les champs de base de données et de table (facultatif)

Cliquez sur Next: Configure Database and Table Fields pour configurer les paramètres spécifiques à AnalyticDB for MySQL V3.0 pour chaque table.

Cette étape est disponible uniquement lorsque Schema Synchronization est sélectionné. Définissez Definition Status sur Tous pour afficher et modifier toutes les tables.

Paramètre	Description
Type	Type de table dans AnalyticDB for MySQL V3.0.
Primary Key Column	Colonnes de clé primaire pour la table. Prend en charge les clés primaires composites.
Distribution Key	Clé de distribution pour la table. Doit correspondre à une ou plusieurs colonnes de la clé primaire.
Partition Key / Partitioning Rules / Partition Lifecycle	Paramètres de partitionnement pour la table. Consultez la section CREATE TABLE.

Étape 8 : Enregistrer la tâche et exécuter la vérification préalable

Pour prévisualiser les paramètres API pour cette configuration de tâche, placez le pointeur sur Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters.
Cliquez sur Next: Save Task Settings and Precheck pour enregistrer et démarrer la vérification préalable.

Si la vérification préalable échoue :

Cliquez sur View Details à côté de chaque élément ayant échoué, corrigez le problème et exécutez à nouveau la vérification préalable.
Si un élément affiche une alerte pouvant être ignorée, cliquez sur Confirm Alert Details, puis sur Ignore, puis sur OK, puis enfin sur Precheck Again. Ignorer les alertes peut entraîner une incohérence des données.

Étape 9 : Acheter une instance

Attendez que le Success Rate atteigne 100%, puis cliquez sur Next: Purchase Instance.
Sur la page d’achat, configurez les éléments suivants.

Paramètre	Description
Billing Method	Subscription : paiement anticipé pour une durée fixe. Plus rentable pour une utilisation à long terme. Paiement à l’utilisation : facturation horaire. Adapté à une utilisation à court terme. Libérez l’instance lorsqu’elle n’est plus nécessaire pour éviter des frais inutiles.
Resource Group Settings	Groupe de ressources pour l’instance de synchronisation. Par défaut : default resource group. Consultez la section Qu’est-ce que Resource Management ?
Instance Class	Niveau de vitesse de synchronisation. Consultez la section Classes d’instance des instances de synchronisation de données.
Subscription Duration	Disponible pour la méthode de facturation par abonnement. Options : 1 à 9 mois, 1 an, 2 ans, 3 ans ou 5 ans.

Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.
Cliquez sur Buy and Start, puis sur OK dans la boîte de dialogue de confirmation.

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

Data Transmission Service:Synchronize data from a self-managed TiDB database to an AnalyticDB for MySQL V3.0 cluster