Data Transmission Service:Migrer des données d'une base de données TiDB auto-gérée vers AnalyticDB for MySQL 3.0

Choisir une méthode

Configurer les paramètres Kafka

Avant de vous connecter à DTS, augmentez les valeurs des paramètres Kafka suivants. Sans ces modifications, le cluster Kafka risque de rejeter les charges utiles volumineuses des journaux binaires provenant de TiDB.

Préparer un cluster Kafka

Utilisez l'une des options suivantes :

• Cluster Kafka auto-géré — Déployez votre propre cluster. Consultez le site officiel d'Apache Kafka.

• Instance ApsaraMQ for Kafka — Créez une instance gérée. Consultez la rubrique Présentation de la prise en main. Déployez l'instance dans le même réseau privé virtuel (VPC) que le serveur de base de données TiDB.

Une fois le cluster Kafka prêt, créez un topic avec exactly one partition. DTS lit uniquement depuis la partition ID 0. Des partitions supplémentaires entraîneront une perte de données.

Utiliser TiDB Binlog

1. Déployez Pump et Drainer sur des serveurs situés sur le même réseau interne que la base de données TiDB. Consultez la rubrique Déploiement du cluster TiDB Binlog.

2. Modifiez le fichier de configuration de Drainer pour qu'il pointe vers le cluster Kafka. Consultez le Guide d'utilisation du client consommateur Binlog.

3. Vérifiez que le serveur TiDB peut atteindre le cluster Kafka.

4. Ajoutez les blocs CIDR des serveurs DTS à la liste d'autorisation de la base de données TiDB. Consultez la rubrique Ajouter les blocs CIDR des serveurs DTS.

Utiliser TiCDC

1. Installez TiCDC à l'aide de TiUP pour ajouter un nouveau nœud TiCDC ou étendre un nœud existant dans le cluster TiDB. Consultez la rubrique Déployer et maintenir TiCDC.

2. Créez un flux de modifications (changefeed) pour répliquer les données incrémentielles vers Kafka. Utilisez la commande tiup cdc cli changefeed create comme point de départ. Consultez la rubrique Répliquer des données vers Kafka.

3. Vérifiez que le serveur TiDB peut atteindre le cluster Kafka.

Base de données source

• Le serveur TiDB doit disposer d'une bande passante sortante suffisante. Une bande passante faible réduit la vitesse de migration.

• Les tables à migrer doivent posséder des contraintes PRIMARY KEY ou UNIQUE avec tous les champs uniques. Les tables dépourvues de ces contraintes peuvent générer des enregistrements en double dans la destination.

• Si vous renommez des tables ou des colonnes pendant la migration, une seule tâche prend en charge jusqu'à 1 000 tables. Pour plus de 1 000 tables, divisez la migration en plusieurs tâches ou migrez la base de données entière en une seule tâche.

• Si vous souhaitez migrer des données incrémentielles depuis la base de données TiDB source, vous devez déployer un cluster Kafka et installer les composants associés pour que la base de données TiDB collecte les données incrémentielles.

• Les index préfixés ne peuvent pas être migrés. Si la base de données source contient des index préfixés, la tâche de migration peut échouer.

Migration incrémentielle

• DTS lit les données uniquement depuis la partition ID 0 du topic Kafka. Configurez le topic avec exactement une partition.

• Après avoir créé une tâche de migration incrémentielle, effectuez rapidement des opérations sur la base de données source ou insérez des données de test pour mettre à jour les informations de décalage (offset) de la tâche. De longs délais avant le premier événement de données peuvent provoquer l'échec de la tâche.

Destination et comportement de la tâche

• Spécifiez une clé primaire personnalisée dans la base de données de destination ou configurez la colonne Primary Key Column à l'étape Configurations for Databases, Tables, and Columns. L'absence de configuration de clé primaire entraîne l'échec de la migration des données.

• Si le cluster AnalyticDB for MySQL V3.0 fait l'objet d'une sauvegarde pendant l'exécution de la tâche DTS, la tâche échoue.

• Si l'utilisation du disque sur les nœuds AnalyticDB for MySQL V3.0 dépasse 80 %, la tâche de migration est retardée et des erreurs sont renvoyées. Estimez l'espace disque requis avant de commencer.

• La migration complète des données augmente la charge sur les bases de données source et de destination. Exécutez les migrations pendant les heures creuses, lorsque la charge CPU est inférieure à 30 %.

• La migration complète des données utilise des opérations INSERT concurrentes, ce qui provoque une fragmentation dans les tables de destination. Une fois la migration complète terminée, la taille de l'espace de table de destination est supérieure à celle de la source.

• Si d'autres sources écrivent dans la destination pendant la migration, une incohérence des données peut survenir.

• DTS utilise la fonction 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 exigences avant de commencer.

• Lors de la migration de schéma, DTS ne prend pas en charge la migration 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 migration terminée.

• DTS tente automatiquement de reprendre les tâches ayant échoué pendant sept jours au maximum. Avant de basculer les charges de travail vers la destination, arrêtez ou libérez toutes les tâches ayant échoué, ou exécutez l'instruction REVOKE pour supprimer les autorisations d'écriture des comptes DTS. Sinon, une tâche reprise risque d'écraser les données de destination.

• Si des instructions DDL échouent dans la destination, la tâche DTS continue de s'exécuter. Consultez les instructions DDL ayant échoué dans les journaux de la tâche. Voir la rubrique Afficher les journaux de tâche.

• 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 la restauration, 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. Pour obtenir la liste des paramètres susceptibles de changer, consultez la rubrique Modifier les paramètres d'instance.

Étape 1 : Accéder à la page Data Migration

Utilisez soit la console DTS, soit la console DMS.

Console DTS

1. Connectez-vous à la console DTS.

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

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

Console DMS

Les étapes peuvent varier selon le mode et la disposition de la console DMS. Consultez les rubriques 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 > DTS (DTS) > Data Migration.

3. Dans la liste déroulante à droite de Data Migration Tasks, sélectionnez la région où résidera l'instance de migration.

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

1. Cliquez sur Create Task.

2. Saisissez un Task Name. DTS génère automatiquement un nom ; spécifiez un nom descriptif pour faciliter l'identification ultérieure de la tâche.

3. Configurez la base de données source :

   Paramètre	Description
   Select Existing Connection	Sélectionnez une instance de base de données enregistrée pour remplir automatiquement les paramètres ci-dessous, ou laissez vide et saisissez manuellement les détails de connexion.
   Database Type	Sélectionnez TiDB.
   Access Method	Sélectionnez la méthode d'accès en fonction de l'emplacement de déploiement de TiDB. Cet exemple utilise Self-managed Database on ECS. Pour d'autres méthodes d'accès, préparez d'abord l'environnement requis. Consultez la rubrique Présentation de la préparation.
   Instance Region	La région où réside la base de données TiDB.
   ECS Instance ID	L'ID de l'instance ECS hébergeant TiDB.
   Port Number	Le port du service TiDB. Par défaut : 4000.
   Database Account	Le compte de la base de données TiDB.
   Database Password	Le mot de passe du compte de base de données.
   Migrate Incremental Data	Sélectionnez Yes si vous souhaitez une migration incrémentielle des données, puis saisissez les détails du cluster Kafka dans la section Configuration du cluster Kafka.

4. Configurez la base de données de destination :

   Paramètre	Description
   Select Existing Connection	Sélectionnez une instance enregistrée pour remplir automatiquement les paramètres ci-dessous, ou laissez vide et saisissez manuellement les détails de connexion.
   Database Type	Sélectionnez AnalyticDB for MySQL 3.0.
   Access Method	Sélectionnez Alibaba Cloud Instance.
   Instance Region	La région où réside le cluster de destination.
   Instance ID	L'ID du cluster AnalyticDB for MySQL V3.0 de destination.
   Database Account	Le compte de base de données pour le cluster de destination. Consultez la section Autorisations requises.
   Database Password	Le mot de passe du compte de base de données.

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

   Les blocs CIDR DTS doivent être ajoutés aux paramètres de sécurité des bases de données source et de destination. Consultez la rubrique Ajouter les blocs CIDR des serveurs DTS .

Étape 3 : Configurer les objets à migrer

Sur la page Configure Objects, définissez les paramètres suivants :

Cliquez sur Next: Advanced Settings.

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

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

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

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

Cliquez sur Next: Configure Database and Table Fields pour définir le Type, Primary Key Column, Distribution Key, Partition Key, Partitioning Rules et Partition Lifecycle pour les tables de destination.

Cette étape est disponible uniquement si Schema Migration est sélectionné. Définissez Definition Status sur All pour afficher et modifier toutes les tables. Pour former une clé primaire composite, spécifiez plusieurs colonnes dans Primary Key Column et désignez-en une ou plusieurs comme Distribution Key et Partition Key . Consultez la rubrique CREATE TABLE .

Étape 7 : Exécuter la vérification préalable

Cliquez sur Next: Save Task Settings and Precheck.

Pour afficher les paramètres API pour cette configuration de tâche, survolez le bouton et cliquez sur Preview OpenAPI parameters avant de continuer.

DTS exécute une vérification préalable avant de démarrer la migration. Si la vérification préalable échoue :

• Cliquez sur View Details à côté de l'élément ayant échoué, résolvez le problème, puis cliquez sur Precheck Again.

• Pour les éléments d'alerte pouvant être ignorés en toute sécurité, cliquez sur Confirm Alert Details > Ignore > OK, puis cliquez sur Precheck Again. Ignorer les alertes peut entraîner une incohérence des données.

Étape 8 : Acheter une instance et démarrer la tâche

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

2. Sur la page Purchase Instance, configurez les éléments suivants :

   Paramètre	Description
   Resource Group	Le groupe de ressources pour l'instance de migration. Par défaut : default resource group. Consultez la rubrique Qu'est-ce que Resource Management ?.
   Instance Class	La classe d'instance détermine la vitesse de migration. Consultez la rubrique Classes d'instances des instances de migration de données.

3. Lisez et acceptez les Conditions de service Data Transmission Service (paiement à l'utilisation).

4. Cliquez sur Buy and Start, puis cliquez sur OK dans la boîte de dialogue de confirmation.

Surveillez la progression de la tâche sur la page Data Migration.

• Les tâches sans migration incrémentielle s'arrêtent automatiquement une fois terminées. Le statut indique Completed.

• Les tâches avec migration incrémentielle s'exécutent en continu. Le statut indique Running. Arrêtez la tâche manuellement après le basculement.