Data Transmission Service:Migrate data from a PolarDB for MySQL cluster to a MaxCompute project

Conditions bloquant la tâche (à résoudre avant de commencer)

Ces conditions entraînent l'échec de la tâche de migration :

• Le serveur sur lequel la base de données source est déployée doit disposer d'une bande passante sortante suffisante. Dans le cas contraire, la vitesse de migration des données diminue.

• Les tables à migrer doivent posséder une contrainte PRIMARY KEY ou UNIQUE avec tous les champs uniques. Sans cela, la destination peut contenir des enregistrements en double.

• Si vous sélectionnez des tables comme objets de migration et devez renommer des tables ou des colonnes, une seule tâche prend en charge jusqu'à 1 000 tables. Les tâches comportant plus de 1 000 tables dans ce mode renvoient une erreur de requête. Configurez plusieurs tâches ou effectuez la migration au niveau de la base de données.

• Pour la migration incrémentielle des données, la journalisation binaire doit être activée et le paramètre loose_polar_log_bin doit être défini sur on. Si la journalisation binaire n'est pas activée, la prévérification échoue et la tâche ne peut pas démarrer. Consultez les rubriques Activer la journalisation binaire et Modifier les paramètres.

• N'exécutez pas d'instructions DDL pour modifier les schémas de base de données ou de tables pendant la migration de schéma ou la migration complète des données. La tâche de migration échoue si les schémas changent en cours de tâche.

• N'utilisez pas d'outils tels que pt-online-schema-change pour les opérations DDL en ligne sur les objets en cours de migration. La tâche de migration échoue.

L'activation de la journalisation binaire sur un cluster PolarDB for MySQL entraîne des frais de stockage pour les fichiers journaux binaires.

Risques liés à l'intégrité des données (à examiner avant de commencer)

Ces conditions peuvent provoquer une incohérence ou une perte de données :

• Les journaux binaires doivent être conservés pendant au moins 3 jours ; il est recommandé de les conserver pendant 7 jours par sécurité. Si DTS ne peut pas lire les journaux binaires, la tâche échoue. Dans des cas exceptionnels, une incohérence ou une perte de données peut survenir. Une conservation des journaux inférieure à la durée requise signifie que l'accord de niveau de service (SLA) pour DTS peut ne pas s'appliquer. Consultez la rubrique Modifier la période de conservation.

• N'écrivez pas de données dans la base de données source lors d'une migration complète uniquement (migration de schéma + migration complète des données sans migration incrémentielle). L'écriture dans la source pendant cette phase provoque une incohérence des données. Pour écrire en toute sécurité dans la source pendant la migration, incluez la migration incrémentielle des données.

• N'écrivez pas de données provenant d'autres sources dans le projet MaxCompute de destination pendant la migration. Les écritures externes provoquent une incohérence des données.

• MaxCompute ne prend pas en charge les contraintes de clé primaire. En cas d'erreurs réseau, DTS peut écrire des enregistrements en double dans le projet MaxCompute.

• DTS réessaie les tâches ayant échoué pendant une durée maximale de 7 jours. Avant de basculer les charges de travail vers la destination, arrêtez ou libérez les tâches ayant échoué. Vous pouvez également révoquer les autorisations d'écriture des comptes DTS sur la destination. À défaut, les données sources écraseront les données de destination lors de la reprise d'une tâche ayant échoué.

Limites opérationnelles

• DTS ne migre pas les nœuds en lecture seule du cluster PolarDB for MySQL source.

• DTS ne migre pas les tables externes Object Storage Service (OSS) du cluster PolarDB for MySQL source.

• DTS ne migre pas les clés étrangères. Les opérations de cascade et de suppression dépendant des clés étrangères ne sont pas répliquées vers la destination.

• Effectuez la migration des données pendant les heures creuses. La migration complète des données utilise les ressources de lecture et d'écriture à la fois sur la source et la destination, ce qui augmente la charge sur les deux serveurs de base de données.

• Après la migration complète des données, l'espace de table de destination est plus grand que celui de la source car les opérations INSERT simultanées provoquent une fragmentation des tables.

• En cas de panne d'une instance DTS, l'équipe d'assistance DTS tente une récupération dans un délai de 8 heures. La récupération peut impliquer le redémarrage de l'instance ou l'ajustement des paramètres de l'instance DTS (et non des paramètres de la base de données). Pour connaître les paramètres pouvant être modifiés, consultez la rubrique Modifier les paramètres de l'instance.

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

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

Utilisez la console DTS ou la console DMS.

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

1. Cliquez sur Create Task.

2. Configurez les paramètres suivants.

Général

Base de données source

Base de données de destination

1. Cliquez sur Test Connectivity and Proceed.

Assurez-vous que les plages CIDR des serveurs DTS sont ajoutées aux paramètres de sécurité des bases de données source et de destination. DTS peut les ajouter automatiquement, ou vous pouvez les ajouter manuellement. Consultez la rubrique Ajouter les adresses IP des serveurs DTS à une liste d'autorisation .

1. Cliquez sur OK pour accorder à DTS les autorisations sur le projet MaxCompute. Cliquez ensuite sur Test Connectivity and Proceed.

Étape 3 : Configurer les objets de migration

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

Migration types

Si vous ignorez Schema Migration , créez manuellement la base de données et les tables de destination avant de démarrer la tâche, et activez le mappage des noms d'objets dans Selected Objects .

Si vous ignorez Incremental Data Migration , n'écrivez pas dans la base de données source pendant la migration afin d'éviter toute incohérence des données.

Configuration des tables

Sélection d'objets

1. Cliquez sur Next: Advanced Settings.

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

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

1. Pour afficher un aperçu des paramètres API avant l'enregistrement, 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 le démarrage de la tâche de migration. La tâche ne démarre qu'après la réussite de cette prévérification.

• Si un élément de vérification échoue, cliquez sur View Details à côté de celui-ci, corrigez le problème, puis cliquez sur Precheck Again.

• Si une alerte se déclenche sur un élément de vérification et que cet élément peut être ignoré en toute sécurité, cliquez sur Confirm Alert Details, puis sur Ignore dans la boîte de dialogue et enfin sur OK. Cliquez ensuite sur Precheck Again. Ignorer une alerte peut entraîner une incohérence des données.

Étape 6 : 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 paramètres suivants.

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

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

La tâche apparaît sur la page Data Migration.

• Les tâches sans migration incrémentielle s'arrêtent automatiquement une fois la migration complète terminée. Le statut affiche Completed.

• Les tâches avec migration incrémentielle s'exécutent en continu. Le statut affiche Running. Arrêtez la tâche manuellement lorsque vous êtes prêt à effectuer le basculement.