Data Transmission Service (DTS) migre les données d'une base de données OceanBase en mode MySQL vers une instance ApsaraDB RDS for MySQL. Suivez ce guide pour configurer et exécuter une tâche de migration de bout en bout.
Prérequis
Avant de commencer, assurez-vous de disposer des éléments suivants :
Une base de données source OceanBase Community Edition V4.x
Une instance de destination ApsaraDB RDS for MySQL dont l'espace de stockage disponible est supérieur à la taille totale des données de la base de données source. Pour les instructions de configuration, consultez Créer une instance ApsaraDB RDS for MySQL
Des comptes de base de données disposant des autorisations requises. Consultez la section Autorisations requises ci-dessous Autorisations requises
Facturation
| Type de migration | Frais de configuration de la tâche | Frais de transfert de données |
|---|---|---|
| Migration du schéma + migration complète des données | Gratuit | Gratuit dans cet exemple |
| Migration incrémentielle des données | Facturé | — |
Pour connaître les tarifs de la migration incrémentielle des données, consultez la page Présentation de la facturation.
Limites
Limites strictes
| Catégorie | Limitation |
|---|---|
| Type de base de données source | OceanBase Community Edition V4.x uniquement |
| Source ApsaraDB for OceanBase | Doit être une instance de cluster en Chine (Shenzhen) ou en Chine (Shanghai). Les instances de locataire ne sont pas prises en charge. |
| Contraintes de table | Les tables doivent comporter des contraintes PRIMARY KEY ou UNIQUE avec tous les champs uniques. L'absence de ces contraintes peut entraîner des doublons dans la destination. |
| Limite de tâches de renommage de table | Lors de la sélection de tables comme objets de migration et du renommage des tables ou des colonnes dans la destination, une seule tâche prend en charge un maximum de 1 000 tables. Pour plus de 1 000 tables, exécutez plusieurs tâches par lots ou migrez la base de données entière. |
| Type de données GEOMETRY | Migration complète des données uniquement. La migration incrémentielle des données GEOMETRY n'est pas prise en charge. |
| Clés étrangères | DTS migre les clés étrangères lors de la migration du schéma. Pendant les migrations complète et incrémentielle, DTS désactive temporairement les vérifications de contrainte de clé étrangère et les opérations en cascade au niveau de la session. Les opérations de suppression en cascade sur la source pendant la migration peuvent provoquer une incohérence des données. |
| Mise en majuscule des noms de colonne | Si les noms de colonne d'une même table de destination ne diffèrent que par la casse, les résultats de la migration peuvent être inattendus, car les noms de colonne MySQL ne sont pas sensibles à la casse par défaut. |
Gestion des types de données
| Type de données | Comportement |
|---|---|
| GEOMETRY | Migration complète des données uniquement. La migration incrémentielle n'est pas prise en charge. |
| FLOAT | DTS utilise ROUND(COLUMN, PRECISION). Si aucune précision n'est spécifiée, DTS utilise par défaut 38 chiffres. |
| DOUBLE | DTS utilise ROUND(COLUMN, PRECISION). Si aucune précision n'est spécifiée, DTS utilise par défaut 308 chiffres. |
Vérifiez que les paramètres de précision par défaut pour FLOAT et DOUBLE répondent à vos exigences avant de démarrer la migration.
Opérations autorisées sur la base de données source pendant la migration
| Phase de migration | Opérations source autorisées |
|---|---|
| Migration du schéma + migration complète des données | Lecture seule. N'exécutez pas d'instructions DDL modifiant les schémas de base de données ou de tables. La tâche échoue si des instructions DDL sont exécutées. |
| Migration complète des données uniquement (sans incrémentiel) | Lecture seule. N'écrivez pas de données dans la base de données source. Les opérations d'écriture entraînent une incohérence des données. |
Points à considérer
Nom de la base de données : si le nom de la base de données source ne respecte pas les conventions de nommage d'ApsaraDB RDS for MySQL, créez manuellement la base de données de destination avant de configurer la tâche. Utilisez ensuite le mappage de nom d'objet pour la renommer lors de l'étape Configurer les objets et les paramètres avancés.
Nouvelle tentative de tâche échouée : DTS tente de relancer les tâches de migration échouées pendant sept jours maximum. Avant de basculer les charges de travail vers la destination, arrêtez ou libérez toutes les tâches échouées, ou exécutez
REVOKEpour supprimer les autorisations d'écriture de DTS sur la destination. Cela empêche les données sources d'écraser les données de destination lors de la reprise de la tâche.Échecs DDL dans la destination : si l'exécution d'instructions DDL échoue dans la destination, la tâche DTS continue de s'exécuter. Consultez les journaux de la tâche pour plus de détails. Voir Afficher les journaux des tâches.
Vérification post-migration : une fois la migration terminée, exécutez
ANALYZE TABLE <table_name>pour confirmer que les données ont été écrites avec succès. Dans les scénarios de basculement de haute disponibilité (HA), les données peuvent exister uniquement en mémoire et être perdues si elles ne sont pas persistantes.Performances de la base de données source : la migration complète des données augmente la charge sur la source et la destination. Exécutez les migrations pendant les heures creuses et activez la limitation du débit si nécessaire.
Taille de l'espace de table de destination : les opérations INSERT concurrentes pendant la migration complète provoquent une fragmentation des tables. L'espace de table de destination sera plus grand que celui de la source une fois la migration terminée.
Opérations SQL prises en charge pour la migration incrémentielle
| Type d'opération | Instructions prises en charge |
|---|---|
| DML | INSERT, UPDATE, DELETE |
| DDL | ALTER TABLE, ALTER VIEW, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, CREATE VIEW, DROP INDEX, DROP TABLE, TRUNCATE TABLE, RENAME TABLE |
Les opérations RENAME TABLE peuvent provoquer une incohérence des données. Si vous renommez une table pendant la migration et que cette table a été ajoutée en tant qu'objet de migration par son nom, les données de la table renommée ne seront pas migrées. Pour éviter cela, ajoutez la base de données (et non la table individuelle) en tant qu'objet de migration, et assurez-vous que les bases de données avant et après le renommage sont incluses.
Autorisations requises
| Base de données | Migration du schéma | Migration complète des données | Migration incrémentielle des données |
|---|---|---|---|
| OceanBase (locataire utilisateur ou locataire standard) | SELECT | SELECT | Locataire standard |
| ApsaraDB RDS for MySQL | Lecture et écriture sur la base de données de destination | Lecture et écriture sur la base de données de destination | Lecture et écriture sur la base de données de destination |
Pour la migration incrémentielle des données, installez oblogproxy sur le serveur hébergeant la base de données source OceanBase et configurez le sys tenant. oblogproxy est un service proxy pour la gestion des journaux incrémentiels. Consultez Installer et déployer oblogproxyInstaller et déployer oblogproxy à l'aide du package d'installation.
Pour créer des comptes de base de données et accorder des autorisations :
Base de données OceanBase gérée par l'utilisateur (site international) : consultez Créer un locataire, Créer un utilisateur et Accorder des autorisations.
OceanBase : Créer un locataire, Créer un utilisateur et Accorder des privilèges
ApsaraDB RDS for MySQL : Créer un compte et Modifier les autorisations du compte
Créer une tâche de migration
Le workflow de migration comprend sept étapes : accéder à la page Tâches de migration de données, configurer les bases de données source et de destination, tester la connectivité, sélectionner les objets de migration, configurer les paramètres avancés, exécuter une pré-vérification et acheter l'instance pour démarrer la tâche.
Étape 1 : Accéder à la page Tâches de migration de données
Connectez-vous à la console Data Management (DMS).
Dans la barre de navigation supérieure, cliquez sur DTS.
-
Dans le volet de navigation de gauche, choisissez DTS (DTS) > Data Migration.
Vous pouvez également accéder directement à la page Tâches de migration de données . La disposition de la console peut varier ; consultez Mode simple et Personnaliser la disposition et le style de la console DMS pour les options de navigation.
-
Dans la liste déroulante située à côté de Tâches de migration de données, sélectionnez la région où résidera l'instance de migration.
Dans la nouvelle console DTS, sélectionnez plutôt la région dans le coin supérieur gauche.
Étape 2 : Configurer les bases de données source et de destination
Cliquez sur Create Task. Sur la page Créer une tâche de migration de données, configurez les paramètres suivants.
Base de données source
| Paramètre | Description |
|---|---|
| Select an existing DMS database instance | Facultatif. Si cette option est sélectionnée, DTS remplit automatiquement les paramètres de la base de données. |
| Database type | Sélectionnez ApsaraDB OceanBase for MySQL. |
| Access method | Sélectionnez en fonction de l'emplacement de déploiement de la base de données source. Cet exemple utilise Adresse IP publique. Pour les bases de données gérées par l'utilisateur, préparez d'abord l'environnement. Consultez Présentation de la préparation. |
| Instance region | Région où réside la base de données source OceanBase. |
| IP Address or Domain Name | Point de terminaison de la base de données source OceanBase. |
| Port number | Port de service. Par défaut : 2881. |
| IP address in log proxy (domain name not supported) | Adresse IP d'oblogproxy pour la base de données source OceanBase. |
| Port in log proxy | Port d'écoute d'oblogproxy. Par défaut : 2983. |
| Database account | Compte de la base de données source OceanBase. Consultez Autorisations requises Autorisations requises. |
| Database password | Mot de passe du compte de base de données. |
Base de données de destination
| Paramètre | Description |
|---|---|
| Select an existing DMS database instance | Facultatif. Si cette option est sélectionnée, DTS remplit automatiquement les paramètres de la base de données. |
| Database type | Sélectionnez MySQL. |
| Access method | Sélectionnez Alibaba Cloud Instance. |
| Instance region | Région où réside l'instance de destination ApsaraDB RDS for MySQL. |
| Replicate data across Alibaba Cloud accounts | Sélectionnez No pour une migration au sein du même compte. |
| RDS instance ID | ID de l'instance de destination ApsaraDB RDS for MySQL. |
| Database account | Compte de la base de données de destination. Consultez Autorisations requises Autorisations requises. |
| Database password | Mot de passe du compte de base de données. |
| Encryption | Sélectionnez Non-encrypted ou Chiffré SSL. Pour utiliser SSL, activez d'abord le chiffrement SSL sur l'instance RDS. Consultez Configurer le chiffrement SSL. |
Étape 3 : Tester la connectivité et configurer la liste blanche d'adresses IP
Cliquez sur Test connectivity and proceed.
Si votre base de données source ou de destination utilise une liste blanche d'adresses IP, ajoutez les blocs CIDR des serveurs DTS à cette liste blanche.
| Emplacement de la base de données | Comment les blocs CIDR sont ajoutés |
|---|---|
| Instances de base de données Alibaba Cloud (ApsaraDB RDS for MySQL, ApsaraDB for MongoDB, etc.) | DTS ajoute automatiquement les blocs CIDR. |
| Bases de données gérées par l'utilisateur sur Elastic Compute Service (ECS) | DTS ajoute automatiquement les blocs CIDR aux règles du groupe de sécurité ECS. Si la base de données est hébergée sur plusieurs instances ECS, ajoutez manuellement les blocs CIDR au groupe de sécurité de chaque instance. |
| Bases de données gérées par l'utilisateur dans des centres de données ou sur des clouds tiers | Ajoutez manuellement les blocs CIDR. Consultez Blocs CIDR des serveurs DTS. |
L'ajout de blocs CIDR publics à une liste blanche de base de données ou à un groupe de sécurité ECS crée des risques de sécurité. Avant de procéder, prenez des mesures préventives : utilisez des identifiants robustes, limitez les ports exposés, authentifiez les appels API, auditez régulièrement les règles de liste blanche et supprimez les blocs CIDR non autorisés. Envisagez d'utiliser Express Connect, VPN Gateway ou Smart Access Gateway pour une connexion plus sécurisée.
Si la base de données source est une instance ApsaraDB for OceanBase, ajoutez manuellement les blocs CIDR des serveurs DTS à la liste blanche d'adresses IP d'ApsaraDB for OceanBase. Utilisez les mêmes blocs CIDR que ceux des bases de données dont la Méthode d'accès est Express Connect, VPN Gateway ou Smart Access Gateway. Consultez Créer un groupe de liste blanche et Blocs CIDR des serveurs DTS.
Étape 4 : Sélectionner les types et objets de migration
Configurez les paramètres suivants.
Types de migration
Sélectionnez le type de migration en fonction de vos exigences en matière de temps d'arrêt.
| Type | Quand l'utiliser | Remarques |
|---|---|---|
| Migration du schéma + migration complète des données | Migration ponctuelle avec une fenêtre de temps d'arrêt planifiée | N'écrivez pas dans la base de données source pendant la migration. |
| Migration du schéma + migration complète des données + migration incrémentielle des données | Migration avec un temps d'arrêt quasi nul ; maintient la synchronisation entre la source et la destination pendant le basculement | Nécessite l'installation d'oblogproxy sur le serveur source. |
Objets et paramètres avancés
| Paramètre | Description |
|---|---|
| Method to migrate triggers in source database | Disponible lorsque la migration du schéma est sélectionnée. Choisissez en fonction de vos besoins. Consultez Synchroniser ou migrer des déclencheurs. |
| Processing mode of conflicting tables | Vérifier et signaler les erreurs : échec de la pré-vérification si la source et la destination partagent des noms de table. Ignorer les erreurs et continuer : ignore la vérification, mais risque une incohérence des données ou un échec partiel de la migration. |
| Capitalization of object names in destination instance | Contrôle la casse des noms de base de données, de tables et de colonnes dans la destination. Par défaut : Politique par défaut de DTS. Consultez Spécifier la casse des noms d'objets. |
| Source objects | Sélectionnez des objets dans la section Source objects et déplacez-les vers Objets sélectionnés à l'aide de l'icône  . Sélection possible au niveau de la colonne, de la table ou de la base de données. |
| Selected objects | Cliquez avec le bouton droit sur un objet pour le renommer. Cliquez sur Batch edit pour renommer plusieurs objets à la fois. Consultez Mapper les noms d'objets. Pour définir des conditions de filtre de ligne, cliquez avec le bouton droit sur une table et spécifiez les conditions WHERE. Consultez Définir des conditions de filtre. |
Le mappage de nom d'objet peut empêcher la migration d'objets dépendants. Le mappage de colonnes pour une migration autre que celle de la table entière, ou les incompatibilités de schéma entre la source et la destination, peuvent entraîner une perte de données pour les colonnes non mappées.
Étape 5 : Configurer les paramètres avancés de la tâche
Cliquez sur Next: Advanced settings et configurez les éléments suivants.
| Paramètre | Description |
|---|---|
| Dedicated cluster for task scheduling | Par défaut, DTS utilise un cluster partagé. Achetez un cluster dédié pour une stabilité accrue. Consultez Qu'est-ce qu'un cluster dédié DTS ?. |
| Set alerts | Configurez l'alerte en cas d'échec de la tâche ou si la latence de migration dépasse un seuil. Sélectionnez Yes pour spécifier un seuil d'alerte et des contacts de notification. Consultez Configurer la surveillance et les alertes. |
| Retry time for failed connections | Plage : 10–1440 minutes. Par défaut : 720 minutes. Nous vous recommandons de définir ce paramètre sur une valeur supérieure à 30. DTS reprend la tâche si la reconnexion est établie dans ce délai ; sinon, la tâche échoue. Si plusieurs tâches partagent la même source ou destination, la valeur définie le plus récemment s'applique. |
| Retry time for other issues | Plage : 1–1440 minutes. Par défaut : 10 minutes. Nous vous recommandons de définir ce paramètre sur une valeur supérieure à 10. Cette valeur doit être inférieure à celle de la Retry time for failed connections. |
| Enable throttling for full data migration | Limite la charge de lecture/écriture sur la source et la destination pendant la migration complète. Définissez les QPS to the source database, les RPS de la migration complète des données et la Vitesse de migration des données (Mo/s). Disponible uniquement lorsque la migration complète des données est sélectionnée. |
| Enable throttling for incremental data migration | Limite la charge pendant la migration incrémentielle. Définissez les RPS of incremental data migration et la Vitesse de migration des données (Mo/s). Disponible uniquement lorsque la migration incrémentielle des données est sélectionnée. |
| Environment tag | Facultatif. Taguez l'instance DTS pour l'identification de l'environnement. |
| Configure ETL | Activez la fonctionnalité extract, transform, and load (ETL) pour appliquer des transformations de données pendant la migration. Consultez Qu'est-ce que l'ETL ? et Configurer l'ETL. |
Étape 6 : Exécuter la pré-vérification
Cliquez sur Next: Save task settings and precheck.
Pour afficher un aperçu des paramètres OpenAPI permettant de configurer cette tâche via l'API, survolez Suivant : Enregistrer les paramètres de la tâche et pré-vérifier et cliquez sur Preview OpenAPI parameters .
DTS exécute une pré-vérification avant que la tâche de migration ne puisse démarrer.
Si un élément de vérification fails : cliquez sur View details, résolvez le problème, puis cliquez sur Precheck again.
Si un élément de vérification affiche une alert : déterminez s'il peut être ignoré en toute sécurité. Pour l'ignorer, cliquez sur View details > Ignore > OK > Precheck again. Ignorer les alertes peut provoquer une incohérence des données.
Attendez que le taux de réussite atteigne 100 %.
Étape 7 : Acheter l'instance de migration et démarrer la tâche
Cliquez sur Next: Purchase instance.
-
Sur la page Purchase instance, configurez les éléments suivants :
Section Paramètre Description Nouvelle classe d'instance Paramètres du groupe de ressources Groupe de ressources pour l'instance de migration. Par défaut : groupe de ressources par défaut. Consultez Qu'est-ce que Resource Management ? Classe d'instance La classe d'instance détermine la vitesse de migration. Consultez Spécifications des instances de migration de données. Lisez et cochez la case Data Transmission Service (Pay-as-you-go) Service Terms.
Cliquez sur Buy and start.
La tâche de migration démarre. Suivez la progression dans la liste des tâches.
FAQ
Que dois-je saisir dans les champs oblogproxy si oblogproxy n'est pas installé ?
Utilisez les valeurs par défaut pour IP address in log proxy (domain name not supported) et Port dans le proxy de journal, et ne sélectionnez pas Incremental data migration pour les Types de migration. La sélection de la migration incrémentielle sans installation d'oblogproxy provoque une erreur.
La région de ma base de données source OceanBase ne figure pas dans la liste déroulante Région de l'instance. Que dois-je sélectionner ?
Sélectionnez la région la plus proche de votre base de données source OceanBase.
Ma base de données source OceanBase est déployée dans un cluster. Que dois-je saisir pour le paramètre Nom de domaine ou IP ?
Définissez ce paramètre sur la valeur que vous avez spécifiée pour OBServer Node lors de la création du cluster.
Comment définir le numéro de port pour un déploiement OceanBase en cluster ?
Si la base de données source OceanBase est en mode autonome, utilisez le port par défaut. Si elle est déployée en cluster, utilisez la valeur que vous avez spécifiée pour SQL Port lors de la création du cluster.
Comment formater le champ Compte de base de données pour la base de données source OceanBase ?
Utilisez le format <username>@<tenant_name>. Par exemple, si l'utilisateur est dtstest et le locataire est dts, saisissez dtstest@dts.