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

Limites de la base de données source

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

• Exigences relatives aux tables :

  • Tables avec clés primaires ou contraintes UNIQUE : assurez-vous que les champs de la table sont uniques pour éviter les données en double dans la destination.

  • Tables sans clés primaires ni contraintes UNIQUE : lors de la configuration de la tâche, sélectionnez Schema Migration sous Migration Types, puis définissez Engine sur duplicate pour ces tables à l'étape Configurations for Databases, Tables, and Columns. Sinon, la tâche peut échouer ou des données peuvent être perdues.

• Limite de mappage de colonnes : si vous mappez des noms de colonnes ou effectuez des modifications par colonne, une seule tâche peut migrer un maximum de 1 000 tables. Pour dépasser cette limite, répartissez les tables sur plusieurs tâches ou migrez la base de données entière sans modifications par colonne.

• Incremental migration only :

  • Activez la journalisation binaire et définissez loose_polar_log_bin sur on. Sans cela, la pré-vérification échoue et la tâche ne peut pas démarrer. Consultez Activer la journalisation binaire et Modifier les paramètres. > Note: L'activation de la journalisation binaire sur un cluster PolarDB for MySQL consomme de l'espace de stockage et engendre des frais.

  • Conservez les journaux binaires pendant au moins 3 jours (7 jours recommandés). Une période de rétention plus courte peut empêcher DTS de lire les journaux requis, ce qui peut entraîner une incohérence ou une perte de données — problèmes non couverts par l'accord de niveau de service (SLA) de DTS. Consultez Modifier la période de rétention.

• Opérations à éviter pendant la migration :

  • N'effectuez pas d'opérations DDL qui modifient le schéma de la base de données ou de la table pendant la migration du schéma ou la migration complète des données. Cela entraînerait l'échec de la tâche.

  • Si vous n'effectuez que la migration complète des données (sans incrémentiel), n'écrivez pas de nouvelles données dans la source. Pour maintenir une cohérence en temps réel, sélectionnez conjointement la migration du schéma, la migration complète des données et la migration incrémentielle des données.

  • Les modifications de données résultant d'opérations non enregistrées dans les journaux binaires, telles que la restauration de sauvegarde physique ou les opérations en cascade, ne sont pas migrées. > Note: Si cela se produit, exécutez à nouveau une migration complète des données lorsque votre activité le permet.

Autres limites

• Nœuds en lecture seule : la migration des nœuds en lecture seule depuis le cluster PolarDB for MySQL source n'est pas prise en charge.

• Tables externes OSS : la migration des tables externes OSS depuis la source n'est pas prise en charge.

• Basculement primaire/secondaire : DTS ne prend pas en charge le basculement primaire/secondaire de la base de données source pendant la migration complète. En cas de basculement, reconfigurez rapidement la tâche.

• Modèles de table de destination : les données ne peuvent être migrées que vers des tables utilisant le modèle Unique Key ou Duplicate Key dans Doris.

  • Modèle Duplicate Key : des données en double peuvent apparaître en cas de nouvelle tentative ou de redémarrage, ou si deux opérations DML ou plus sont effectuées sur la même ligne après le démarrage de la tâche. Dédupliquez à l'aide des colonnes supplémentaires (_is_deleted, _version, _record_id). DTS convertit les instructions UPDATE et DELETE en instructions INSERT pour les tables du modèle Duplicate Key.

• Paramètre bucket_count : seul paramètre configurable dans la zone Selected Objects. Doit être un entier positif. Valeur par défaut : auto.

• Création de cluster : ne créez pas de clusters dans la base de données Doris de destination pendant la migration. Si cela provoque un échec, redémarrez l'instance de migration pour reprendre.

• Exigences relatives aux noms d'objets :

  • Doris prend uniquement en charge les noms de bases de données et de tables commençant par une lettre. Utilisez la fonctionnalité de mappage de nom d'objet pour renommer les objets qui ne satisfont pas à cette exigence.

  • Si un nom de base de données, de table ou de colonne contient des caractères chinois, utilisez la fonctionnalité de mappage de nom d'objet pour le renommer (par exemple, en équivalent anglais). Sinon, la tâche peut échouer.

• Restrictions DDL : les opérations DDL qui modifient simultanément plusieurs colonnes, ou qui modifient successivement la même table, ne sont pas prises en charge.

• Nœuds Backend (BE) : n'ajoutez pas de nœuds BE à la base de données Doris de destination pendant la migration. Si cela provoque un échec, redémarrez l'instance de migration pour reprendre.

• Fusion multi-tables : lors de la migration des données de plusieurs tables sources vers une seule table de destination, tous les schémas de tables sources doivent être cohérents. Des schémas incohérents peuvent entraîner une incohérence des données ou l'échec de la tâche.

• Longueur VARCHAR : dans PolarDB for MySQL, VARCHAR(M) spécifie la longueur en caractères. Dans Doris, VARCHAR(N) spécifie la longueur en octets. Si vous n'utilisez pas la migration de schéma DTS, définissez la longueur du champ VARCHAR dans Doris à quatre fois la longueur MySQL.

• Outils DDL en ligne :

  • DTS prend en charge les modifications DDL en ligne effectuées à l'aide de DMS ou gh-ost. DTS migre uniquement les instructions DDL d'origine, pas les données des tables temporaires. Cependant, la table de destination peut être verrouillée pendant ce processus.

  • DTS ne prend pas en charge les modifications DDL en ligne effectuées à l'aide d'outils tels que pt-online-schema-change sur la source. De telles modifications sur la source peuvent entraîner une perte de données ou l'échec de la tâche.

• Impact sur les performances : pendant la migration complète, DTS lit depuis la source et écrit dans la destination, augmentant la charge du serveur de base de données. Exécutez la migration pendant les heures creuses lorsque la charge CPU est inférieure à 30 %.

• Fragmentation de l'espace de table : les opérations INSERT concurrentes pendant la migration complète provoquent une fragmentation de la table dans la destination. Après la migration complète, l'espace de table utilisé dans la destination sera plus grand que dans la source.

• Écritures concurrentes vers la destination : l'écriture de données provenant d'autres sources vers la destination pendant la migration peut entraîner une incohérence des données.

• Table heartbeat : DTS exécute périodiquement CREATE DATABASE IF NOT EXISTS \ test\`` sur la source pour faire avancer le décalage du journal binaire.

• Latence de migration incrémentielle : DTS utilise une politique de synchronisation par lots pour réduire la charge sur la destination. Par défaut, DTS écrit dans un seul objet au maximum toutes les 5 secondes, ce qui entraîne une latence de synchronisation typique inférieure à 10 secondes. Pour réduire la latence, ajustez le paramètre selectdb.reservoir.timeout.milliseconds dans la console. Plage valide : 1 000–10 000 millisecondes.

  Une valeur plus petite augmente la fréquence d'écriture, ce qui peut augmenter la charge et le temps de réponse (RT) de la destination et, par conséquent, augmenter la latence de synchronisation. Ajustez en fonction de la charge de la destination.

• Récupération d'instance : si une instance DTS échoue, le support technique tente une récupération dans un délai de 8 heures. Pendant la récupération, DTS peut redémarrer l'instance ou ajuster ses paramètres (uniquement les paramètres de l'instance DTS, pas les paramètres de la base de données). Consultez Modifier les paramètres de l'instance pour connaître les paramètres susceptibles d'être modifiés.

• La migration de données de type VECTOR n'est pas prise en charge.

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

Utilisez l'une des méthodes suivantes pour accéder à la page Data Migration et sélectionnez la région où réside l'instance de migration.