Data Transmission Service:Migrer les données d'une base de données TiDB auto-gérée vers un cluster PolarDB for MySQL

Limites de la base de données source

• Bande passante sortante : Le serveur de la base de données source doit disposer d'une bande passante sortante suffisante. Une bande passante insuffisante réduit la vitesse de migration.

• Clé primaire ou contrainte UNIQUE : Les tables doivent posséder une PRIMARY KEY ou une contrainte UNIQUE avec tous les champs uniques. Sans ces contraintes, la base de données de destination peut contenir des enregistrements en double.

• Limite de tables par tâche : Lors de la migration de tables individuelles avec des modifications au niveau des colonnes (telles que le renommage des colonnes), une seule tâche prend en charge jusqu'à 1 000 tables. Pour plus de 1 000 tables, répartissez le travail sur plusieurs tâches ou migrez la base de données entière.

• Restrictions DDL pendant la migration : Pendant la migration de schéma et la migration complète des données, n'effectuez pas d'opérations DDL modifiant le schéma de la base de données ou des tables. La tâche de migration échoue si des opérations DDL sont détectées.

• Index de préfixe : Les métadonnées TiDB ne stockent pas les longueurs des index de préfixe. Après la migration, les longueurs des index de préfixe sont perdues, ce qui peut empêcher l'instance de fonctionner. Corrigez manuellement les longueurs des index de préfixe pour toutes les tables concernées après la migration.

• Exigences relatives aux données incrémentielles : La migration incrémentielle des données nécessite un cluster Kafka et les composants TiDB Binlog ou TiCDC. Consultez (Facultatif) Configurer la collecte de données incrémentielles.

Autres limites

• Incremental data partition : DTS lit les données incrémentielles uniquement à partir de l'ID de partition 0 dans le topic Kafka.

• Initialisation de la position : Après avoir créé une tâche avec migration incrémentielle, effectuez des modifications ou insérez des données de test dans la base de données source rapidement pour mettre à jour les informations de position. Ne pas le faire peut entraîner l'échec de la tâche en raison d'une latence excessive.

• Caractères sur 4 octets : Si les données incluent des caractères rares ou des emojis (caractères sur 4 octets), la base de données et les tables de destination doivent utiliser le jeu de caractères UTF8mb4. Si vous utilisez la migration de schéma DTS, définissez également le paramètre d'instance character_set_server sur UTF8mb4 dans la base de données de destination.

• Utilisation des ressources lors de la migration complète : La migration complète des données consomme des ressources de lecture et d'écriture sur les bases de données source et de destination, augmentant ainsi leur charge. Évaluez les performances de la base de données avant la migration et exécutez la migration complète pendant les heures creuses (par exemple, lorsque la charge CPU est inférieure à 30 %).

• Taille de l'espace tablespace après la migration complète : Les opérations INSERT concurrentes pendant la migration complète des données provoquent une fragmentation des tables. L'espace tablespace dans la base de données de destination sera plus grand que dans la base de données source une fois la migration terminée.

• Écritures dans la destination pendant la migration : L'écriture dans la base de données de destination pendant la migration peut entraîner une incohérence des données entre la source et la destination.

• Précision FLOAT et DOUBLE : DTS utilise ROUND(COLUMN,PRECISION) pour lire 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 paramètres de précision répondent à vos exigences.

• Reprise automatique : DTS tente automatiquement de reprendre les tâches ayant échoué au cours des sept derniers jours. Avant de basculer les charges de travail vers l'instance de destination, arrêtez ou libérez la tâche DTS, ou exécutez REVOKE pour supprimer les autorisations d'écriture du compte DTS sur l'instance de destination.

• Échecs DDL : Si une instruction DDL échoue dans la base de données de destination, la tâche DTS continue de s'exécuter. Affichez les instructions DDL ayant échoué dans les journaux de la tâche. Consultez Afficher les journaux de tâche.

• Intervention du support technique : Si une tâche DTS échoue, le support technique tente de la restaurer dans un délai de 8 heures. Pendant la restauration, la tâche peut être redémarrée et les paramètres de la tâche (et non les paramètres de la base de données) peuvent être modifiés. Pour connaître les paramètres susceptibles d'être modifiés, consultez la section Modifier les paramètres de l'instance.

Étape 1 : Configurer un cluster Kafka

Utilisez l'une des options suivantes :

• Cluster Kafka auto-géré : Déployez Apache Kafka en suivant la documentation Apache Kafka.

  Avertissement

  Pour gérer le volume des données de journal binaire provenant de TiDB, augmentez les paramètres suivants dans votre configuration Kafka. Consultez Configuration Kafka.

  Composant	Paramètre	Pourquoi
  Broker	message.max.bytes	Définit la taille maximale d'un message accepté par le broker. Les événements de journal binaire TiDB peuvent être volumineux, donc la limite par défaut provoque des échecs d'écriture.
  Broker	replica.fetch.max.bytes	Définit le nombre maximal d'octets qu'un follower peut récupérer par requête. Doit être au moins aussi grand que message.max.bytes pour répliquer les messages de grande taille.
  Consumer	fetch.message.max.bytes	Définit le nombre maximal d'octets qu'un consumer récupère par partition. Doit être au moins aussi grand que message.max.bytes afin que DTS puisse lire les événements complets.

• Message Queue for Apache Kafka : Utilisez le service Kafka géré par Alibaba Cloud. Consultez Premiers pas.

  Déployez l'instance Message Queue for Apache Kafka dans le même virtual private cloud (VPC) que le serveur de la base de données source pour réduire la latence réseau et assurer une connectivité stable.

Étape 2 : Créer un topic Kafka

Créez un topic dans le cluster Kafka ou l'instance Message Queue for Apache Kafka.

Étape 3 : Configurer TiDB Binlog ou TiCDC

Choisissez une méthode en fonction de votre environnement :

<details> <summary>Option A : TiDB Binlog</summary>

Pour minimiser l'impact de la latence réseau, déployez le composant Pump, le composant Drainer et le cluster Kafka sur des serveurs partageant le même réseau interne que le serveur de la base de données TiDB source.

1. Déployez les composants Pump et Drainer. Consultez Déploiement du cluster TiDB Binlog.

2. Modifiez le fichier de configuration Drainer pour définir Kafka comme sortie. Consultez Développement personnalisé Kafka.Développement personnalisé Kafka

3. Vérifiez que le serveur de la base de données TiDB peut se connecter au cluster Kafka.

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

</details>

<details> <summary>Option B : TiCDC</summary>

1. Installez le composant TiCDC. Utilisez TiUP pour ajouter ou mettre à l'échelle TiCDC sur votre cluster TiDB existant. Consultez Déployer TiCDC.

2. Répliquez les données incrémentielles vers Kafka en utilisant tiup cdc cli changefeed create \ comme première commande. Consultez Répliquer les données vers Kafka.

3. Vérifiez que le serveur de la base de données TiDB peut se connecter au cluster Kafka.

</details>

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

Utilisez l'une des méthodes suivantes :

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

1. Cliquez sur Create Task.

2. Sur la page de configuration de la tâche, configurez les bases de données source et de destination.

Paramètres de la base de données source

Paramètres de la base de données de destination

Étape 3 : Tester la connectivité

Dans la partie inférieure de la page, cliquez sur Test Connectivity and Proceed. Dans la boîte de dialogue CIDR Blocks of DTS Servers, cliquez sur Test Connectivity.

Assurez-vous que les blocs CIDR des serveurs DTS sont ajoutés aux paramètres de sécurité des bases de données source et de destination. Consultez Ajouter les blocs CIDR des serveurs DTS .

Étape 4 : Configurer les objets de migration

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

Types de migration et gestion des conflits

Sélection d'objets

Paramètre	Description
Source Objects	Sélectionnez les tables ou bases de données à migrer. Cliquez sur pour déplacer les objets sélectionnés vers Selected Objects.
Selected Objects	Cliquez avec le bouton droit sur un objet pour le renommer. Consultez [Mapper le nom d'un seul objet](https://www.alibabacloud.com/help/en/dts/user-guide/map-object-names#section-g21-1wy-98l). Cliquez sur Batch Edit pour renommer plusieurs objets à la fois. Consultez [Mapper plusieurs noms d'objets à la fois](https://www.alibabacloud.com/help/en/dts/user-guide/map-object-names#section-2wn-exv-fib). Cliquez avec le bouton droit sur une table pour configurer une condition de filtre WHERE. Remarque Le renommage d'un objet peut empêcher la migration des objets dépendants. Remarque

1. Cliquez sur Next: Advanced Settings.

Advanced settings

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

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

1. Pour afficher un aperçu des paramètres API pour cette tâche, placez le pointeur sur Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters.

2. Cliquez sur Next: Save Task Settings and Precheck.

DTS exécute une pré-vérification avant de démarrer la migration. La tâche ne démarre qu'après la réussite de la pré-vérification.

Pour les éléments de pré-vérification ayant échoué, cliquez sur View Details pour diagnostiquer le problème, le résoudre, puis relancer la pré-vérification.

Pour les éléments d'alerte : si l'alerte ne peut pas être ignorée, corrigez le problème et relancez la pré-vérification. Si l'alerte peut être ignorée, cliquez sur Confirm Alert Details , puis cliquez sur Ignore > OK > Precheck Again .

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

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

2. Sur la page Purchase Instance, configurez la classe d'instance.

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

2. Cliquez sur Buy and Start, puis cliquez sur OK.

La tâche apparaît sur la page Data Migration. Surveillez sa progression à cet endroit.