Data Transmission Service:Migrer des données d'ApsaraDB RDS for PostgreSQL vers ApsaraDB for SelectDB

Exigences relatives à la base de données source

• Bande passante : le serveur hébergeant la base de données source doit disposer d'une bande passante sortante suffisante. Sinon, la vitesse de migration des données sera affectée.

• Tables avec clés primaires ou contraintes UNIQUE : assurez-vous que les champs de la table sont uniques. Sinon, des données en double peuvent exister dans la base de données de destination.

  Si la table de destination recevant les données n'est pas créée par DTS (c'est-à-dire si Schema Migration n'est pas sélectionné), assurez-vous que la table de destination possède la même clé primaire ou la même contrainte UNIQUE non nulle que la table source. Sinon, des données en double peuvent apparaître dans la base de données de destination.

• Tables sans clé primaire ni contrainte UNIQUE : sélectionnez Schema Migration lors de la configuration de la tâche et définissez le moteur de table sur duplicate.

• Nom de la base de données : le nom de la base de données ne peut pas contenir de trait d'union (-). Par exemple, dts-testdata n'est pas pris en charge.

• Nombre de tables : lors d'une migration au niveau des tables avec mappage des noms de colonnes, une seule tâche prend en charge un maximum de 1 000 tables. Pour les migrations plus importantes, répartissez les tables sur plusieurs tâches ou migrez la base de données entière.

• Opérations DDL : n'effectuez pas d'opérations DDL sur la base de données source pendant la migration complète des données.

• Taille des données : si une seule ligne de données de modification incrémentielle dépasse 256 Mo, l'instance de migration échoue et ne peut pas être récupérée. Vous devez reconfigurer l'instance de migration.

• Write-Ahead Logging (WAL) :

  • Définissez wal_level sur logical.

  • Pour la migration incrémentielle uniquement : conservez les journaux WAL pendant plus de 24 heures.

  • Pour la migration complète + incrémentielle : conservez les journaux WAL pendant au moins 7 jours. Vous pouvez modifier la période de rétention des journaux à plus de 24 heures une fois la migration complète terminée.

  Important

  Si la rétention des journaux WAL est inférieure aux exigences de DTS et que la tâche échoue en raison de journaux manquants, cela n'est pas couvert par l'accord de niveau de service (SLA) de DTS.

• Basculement des slots de réplication logique : l'instance RDS PostgreSQL doit prendre en charge et avoir activé le basculement des slots de réplication logique. Consultez Basculement des slots de réplication logique.

• Transactions de longue durée : si la base de données source contient des transactions de longue durée et que la tâche inclut une migration incrémentielle, les données WAL s'accumulent jusqu'à ce que la transaction soit validée. Surveillez l'espace disque de la source pour éviter la saturation.

• Mises à niveau majeures : ne mettez pas à niveau la version majeure de la base de données source pendant l'exécution de l'instance de migration. Cela entraînerait un échec permanent de l'instance.

Exigences relatives à la destination SelectDB

• Les tables doivent utiliser le moteur Unique ou Duplicate. Consultez Modèle de données pour obtenir des conseils.

• Si la table de destination utilise le moteur Unique, toutes les clés uniques de la table de destination doivent également exister dans la table source et être incluses dans les objets de migration.

• Les noms de bases de données et de tables doivent commencer par une lettre. Utilisez la fonctionnalité de mappage des noms d'objets pour renommer les objets qui ne répondent pas à cette exigence.

• Les noms d'objets contenant des caractères chinois doivent être renommés en équivalents ASCII à l'aide du mappage des noms d'objets. Sinon, la tâche peut échouer.

• Une instance de migration ne peut migrer qu'une seule base de données. Pour migrer plusieurs bases de données, configurez une instance de migration distincte pour chacune.

• N'ajoutez pas de nœuds backend (BE) à la base de données SelectDB pendant la migration. Si la tâche échoue pour cette raison, redémarrez l'instance de migration pour reprendre.

• Ne créez pas de clusters dans l'instance de destination SelectDB pendant la migration. Si la tâche échoue pour cette raison, redémarrez l'instance de migration pour reprendre.

• DTS valide le contenu des données mais ne valide pas les métadonnées telles que les séquences. Validez ces métadonnées manuellement.

Exigences relatives à la migration incrémentielle

• Exécutez la commande suivante sur chaque table à migrer avant d'écrire des données dans la source :

  ALTER TABLE schema.table REPLICA IDENTITY FULL;

  Remplacez schema et table par le nom du schéma réel et le nom de la table. Exécutez cette commande pendant les heures creuses et ne verrouillez pas les tables pendant son exécution afin d'éviter les interblocages.

  Si vous ignorez l'élément de précontrôle associé, DTS exécute automatiquement cette commande lors de l'initialisation de l'instance. Cela s'applique lorsque l'instance s'exécute pour la première fois, ou lorsque la granularité de l'objet de migration est définie sur Schema et qu'une nouvelle table est créée ou qu'une table existante est reconstruite à l'aide de la commande RENAME.

• Les opérations SQL prises en charge pour la migration incrémentielle sont les suivantes :

  Type d'opération	Instructions SQL
  DML	INSERT, UPDATE, DELETE
  DDL	ADD COLUMN, DROP COLUMN

• DTS convertit les instructions UPDATE et DELETE en instructions INSERT pour les tables utilisant le moteur Duplicate.

• DTS ne peut pas migrer les tables d'extension TimescaleDB ni les tables avec héritage cross-schema.

• Lors de la migration de tables partitionnées, incluez à la fois la table parente et toutes les tables enfants dans les objets de migration. La table parente elle-même ne stocke pas de données, mais son exclusion entraîne une incohérence des données.

• Pour les scénarios de fusion multi-tables (plusieurs tables sources vers une table de destination), toutes les tables sources doivent avoir des schémas identiques.

Cas particuliers

Comportement interne de DTS

Pendant la migration, DTS crée les objets suivants dans la base de données source. Ne les supprimez pas ; ils sont supprimés automatiquement lorsque l'instance DTS est libérée :

• Tables temporaires : public.dts_pg_class, public.dts_pg_attribute, public.dts_pg_type, public.dts_pg_enum, public.dts_postgres_heartbeat, public.dts_ddl_command, public.dts_args_session, public.aliyun_dts_instance

• Slot de réplication (préfixe : dts_sync_) : utilisé pour extraire les journaux incrémentiels des 15 dernières minutes. DTS nettoie ce slot en cas d'échec de la migration ou de libération de l'instance.

  Si vous modifiez le mot de passe du compte de la base de données source ou retirez les adresses IP de DTS de la liste d'autorisation pendant la migration, le slot de réplication ne peut pas être nettoyé automatiquement. Nettoyez-le manuellement pour éviter l'accumulation sur le disque. En cas de basculement primaire/secondaire, connectez-vous à la base de données secondaire pour effectuer le nettoyage.

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

Utilisez l'une des consoles suivantes pour accéder à la page Data Migration.

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

Cliquez sur Create Task pour ouvrir la page de configuration de la tâche, puis configurez les paramètres suivants.

Task name

Source database

Destination database

Étape 3 : Tester la connectivité et configurer les objets

1. Cliquez sur Test Connectivity and Proceed.

   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 des adresses IP de serveur DTS à une liste d'autorisation .

2. Sur la page Configure Objects, configurez les paramètres suivants :

   Paramètre	Description
   Migration Types	Sélectionnez en fonction de votre stratégie de migration. Consultez Choisir un type de migration. Pour une migration sans temps d'arrêt, sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration. Pour une migration ponctuelle, sélectionnez Schema Migration et Full Data Migration.
   Processing Mode of Conflicting Tables	Precheck and Report Errors (par défaut) : la tâche échoue lors du précontrôle si des tables portant le même nom existent dans la destination. Ignore Errors and Proceed : DTS ignore la vérification. À utiliser avec prudence — une incohérence des données peut survenir si les schémas diffèrent.
   Capitalization of Object Names in Destination Instance	Détermine la mise en majuscule des noms de bases de données, de tables et de colonnes dans la destination. L'option DTS default policy est sélectionnée par défaut. Consultez Spécifier la mise en majuscule des noms d'objets dans l'instance de destination.
   Source Objects	Sélectionnez les objets à migrer au niveau du schéma ou de la table, puis cliquez sur l'icône pour les ajouter à Selected Objects.
   Selected Objects	Cliquez avec le bouton droit sur un objet pour le renommer, définir des conditions de filtre ou sélectionner des opérations SQL pour la migration incrémentielle. Pour définir le paramètre bucket_count, cliquez avec le bouton droit sur une table, accédez à Parameter Settings, activez le paramètre et spécifiez une valeur. Pour supprimer un objet, cliquez dessus puis sur l'icône de suppression.

   - Le paramètre bucket_count doit être un entier positif. La valeur par défaut est auto . - Si vous renommez un objet à l'aide du mappage des noms d'objets, les autres objets qui en dépendent peuvent ne pas être migrés. - Pour filtrer les lignes, cliquez avec le bouton droit sur une table dans Selected Objects et spécifiez les conditions WHERE. Consultez Spécifier des conditions de filtre .

3. Cliquez sur Next: Advanced Settings et configurez les paramètres facultatifs suivants :

   Paramètre	Description
   Dedicated Cluster for Task Scheduling	Par défaut, les tâches s'exécutent sur le cluster partagé. Pour une stabilité accrue, achetez un cluster dédié. Consultez Qu'est-ce qu'un cluster dédié DTS ?.
   Retry Time for Failed Connections	Durée pendant laquelle DTS effectue des tentatives avant de marquer la tâche comme échouée en raison de problèmes de connexion. Plage : 10–1 440 minutes. Par défaut : 720 minutes. Définissez une valeur d'au moins 30 minutes.
   Retry Time for Other Issues	Durée pendant laquelle DTS effectue des tentatives avant d'échouer en raison d'erreurs DDL ou DML. Plage : 1–1 440 minutes. Par défaut : 10 minutes. Doit être inférieure à Retry Time for Failed Connections.
   Enable Throttling for Full Data Migration	Limite le débit de lecture/écriture pendant la migration complète pour réduire la charge de la base de données. Configurez Queries per second (QPS) to the source database, RPS of Full Data Migration et Data migration speed for full migration (MB/s).
   Enable Throttling for Incremental Data Migration	Limite le débit pendant la migration incrémentielle. Configurez RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s).
   Environment Tag	Facultatif. Étiquetez l'instance pour l'identification de l'environnement.
   Configure ETL	Sélectionnez Yesalert notification settings pour activer la fonctionnalité extract, transform, and load (ETL). Consultez Configurer ETL dans une tâche de migration ou de synchronisation de données.
   Monitoring and Alerting	Sélectionnez Yes pour recevoir des alertes lorsque la tâche échoue ou lorsque la latence de migration dépasse un seuil. Consultez Configurer la surveillance et les alertes.

4. (Facultatif) Cliquez sur Next: Configure Database and Table Fields pour définir la Primary Key Column, la Distribution Key et le Engine pour les tables de destination.

   - Cette étape est disponible uniquement si vous avez sélectionné Schema Migration pour Migration Types . Définissez Definition Status sur All pour modifier toutes les tables. - La Primary Key Column peut être une clé primaire composite. Sélectionnez une ou plusieurs colonnes de la Primary Key Column comme Distribution Key . - Pour les tables sans clé primaire ni contrainte UNIQUE, définissez Engine sur duplicate . Sinon, l'instance de migration peut échouer ou des données peuvent être perdues.

Étape 4 : Exécuter le précontrôle

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

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

2. Attendez que le précontrôle soit terminé. Si des éléments échouent :

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

   • Pour les éléments d'alerte pouvant être ignorés, cliquez sur Confirm Alert Details, puis cliquez sur Ignore > OK > Precheck Again.

   Important

   Ignorer les éléments d'alerte peut entraîner une incohérence des données. Procédez avec prudence.

Étape 5 : Acheter l'instance et démarrer la migration

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 :

   Paramètre	Description
   Resource Group	Groupe de ressources pour l'instance de migration. Par défaut : default resource group. Consultez Qu'est-ce que Resource Management ?
   Instance Class	Contrôle la vitesse de migration. Consultez Classes d'instances des instances de migration de données.

3. Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms, puis cliquez sur Buy and Start > OK.

Vérifier l'état de la migration

Après le démarrage de la tâche, accédez à la page Data Migration pour surveiller la progression :

• Migration complète uniquement : la tâche s'arrête automatiquement une fois terminée. Le Status passe à Completed.

• Migration complète + incrémentielle : la phase incrémentielle s'exécute en continu. Le Status affiche Running. Arrêtez la tâche manuellement lorsque vous êtes prêt à basculer vers la destination.