Data Transmission Service:Migrer des données de PolarDB for PostgreSQL vers SelectDB

Base de données source

• Les tables à migrer doivent posséder une clé primaire ou un index UNIQUE NOT NULL. Selon la configuration de vos tables :

  • Si toutes les tables ont une clé primaire ou un index unique non nul : assurez-vous que les champs des tables sont uniques, faute de quoi des données dupliquées peuvent apparaître dans la base de données de destination.

  • Si certaines tables n'ont ni clé primaire ni index unique non nul : lors de la configuration de l'instance, sélectionnez Schema Migration sous Migration Types, puis à l'étape Configurations for Databases, Tables, and Columns, définissez Engine sur duplicate pour ces tables. Sinon, l'instance de migration risque d'échouer ou des données peuvent être perdues.

• Pendant la migration du schéma et la migration complète des données, n'exécutez pas d'opérations DDL modifiant le schéma de la base de données ou des tables, car cela entraînerait l'échec de la tâche de migration.

• Lors de la migration incrémentielle des données, toute modification de données unique dépassant 256 Mo provoque l'échec irrécupérable de l'instance de migration. Vous devrez alors reconfigurer l'instance de migration.

• Les transactions de longue durée pendant la migration incrémentielle peuvent provoquer l'accumulation de journaux WAL (Write-Ahead Logging), ce qui risque de saturer l'espace de stockage de la base de données source.

Base de données de destination

• Les tables de l'instance SelectDB de destination doivent utiliser le moteur Unique ou Duplicate.

• 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 commencent pas par une lettre ou dont le nom contient des caractères chinois.

• N'ajoutez pas de nœuds backend (BE) à l'instance SelectDB pendant la migration, sous peine d'échec de la tâche. Redémarrez l'instance de migration pour reprendre.

• Ne créez pas de clusters dans l'instance SelectDB de destination pendant la migration, sous peine d'échec de la tâche. Redémarrez l'instance de migration pour reprendre.

Comportement de la migration

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

• DTS ne prend pas en charge les tables d'extension TimescaleDB ni les tables avec héritage inter-schémas.

• DTS ne valide pas les métadonnées telles que les séquences. Vérifiez manuellement la validité des métadonnées après la migration.

• Lors de la migration de tables partitionnées, incluez à la fois la table parente et toutes les partitions enfants comme objets de migration. La table parente d'une table partitionnée PostgreSQL ne stocke pas directement les données ; toutes les données résident dans les partitions enfants. L'absence de partitions enfants entraîne des incohérences de données.

• Dans un scénario de fusion de plusieurs tables (plusieurs tables sources migrées vers une seule table de destination), les schémas de toutes les tables sources doivent être identiques.

• Il est impossible d'exécuter des opérations DDL modifiant simultanément plusieurs colonnes ou modifiant la même table successivement.

• DTS crée les tables temporaires suivantes dans la base de données source lors de la migration incrémentielle. Ne les supprimez pas, car leur suppression entraîne l'échec de la tâche. DTS les supprime automatiquement après la libération de l'instance de migration : 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 et public.aliyun_dts_instance

Comportement du moteur Unique

Si la table de destination utilise le moteur Unique, toutes les clés uniques de la table de destination doivent exister dans la table source et être incluses comme objets de migration. Dans le cas contraire, des incohérences de données peuvent survenir.

Comportement du moteur Duplicate

Si la table de destination utilise le moteur Duplicate :

• DTS convertit les instructions UPDATE et DELETE en instructions INSERT.

• Des lignes dupliquées peuvent apparaître dans la destination dans les cas suivants : une nouvelle tentative a eu lieu, l'instance de migration a redémarré, ou deux opérations DML ou plus ont été effectuées sur la même ligne après le début de la migration. Utilisez les colonnes supplémentaires (_is_deleted, _version et _record_id) pour identifier et supprimer les doublons.

Exigences relatives à la migration incrémentielle des données

Avant d'écrire des données dans les tables incluses dans une migration incrémentielle, exécutez la commande suivante sur chaque table de la base de données source :

ALTER TABLE schema.table REPLICA IDENTITY FULL;

Remplacez schema et table par le nom réel du schéma et de la table. Exécutez cette commande en dehors des heures de pointe et ne verrouillez pas les tables, car le verrouillage peut provoquer un blocage (deadlock).

Si vous ignorez l'élément de pré-vérification associé, DTS exécute cette commande automatiquement lors de l'initialisation de l'instance, c'est-à-dire lors de la première exécution de l'instance, ou lorsque la granularité de l'objet de migration est définie sur Schema et qu'une nouvelle table est créée ou reconstruite à l'aide de la commande RENAME.

Gestion des slots de réplication

DTS crée un slot de réplication avec le préfixe dts_sync_ dans la base de données source pour répliquer les données incrémentielles. Le slot conserve jusqu'à 15 minutes de journaux incrémentiels.

Lorsqu'une tâche de migration échoue ou que l'instance de migration est libérée, DTS tente de nettoyer automatiquement le slot de réplication. Un nettoyage manuel est nécessaire dans les cas suivants :

• Le mot de passe du compte de la base de données source a été modifié pendant la migration.

• L'adresse IP de DTS a été retirée de la liste d'autorisation pendant la migration.

• Un basculement primaire/secondaire s'est produit : connectez-vous à la base de données secondaire pour effectuer le nettoyage.

Les slots de réplication non nettoyés s'accumulent et consomment de l'espace disque, ce qui peut rendre la base de données source indisponible.

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

Utilisez l'une des méthodes suivantes :

Étape 2 : Créer une tâche

Cliquez sur Create Task pour accéder à la page de configuration de la tâche.

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

Configurez les paramètres décrits dans le tableau suivant.

Une fois la configuration terminée, cliquez sur Test Connectivity and Proceed en bas de la page.

Les adresses IP des serveurs DTS doivent être ajoutées aux paramètres de sécurité des bases de données source et de destination. DTS peut ajouter ces adresses IP automatiquement, ou vous pouvez les ajouter manuellement. Consultez Ajouter les adresses IP des serveurs DTS à une liste d'autorisation .

Étape 4 : Configurer les objets de migration

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

Paramètre	Description
Migration Types	Sélectionnez les types de migration selon votre stratégie : <br>- Full migration (aucune tolérance aux interruptions) : Sélectionnez Schema Migration et Full Data Migration. Arrêtez toutes les écritures sur la source avant de commencer. <br>- Online migration (zéro interruption) : Sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration.
Processing Mode of Conflicting Tables	- Precheck and Report Errors : DTS vérifie la présence de tables portant le même nom dans la destination. Si des doublons existent, la pré-vérification échoue. Pour résoudre ce problème, renommez la table de destination à l'aide de la fonctionnalité de mappage des noms d'objets. <br>- Ignore Errors and Proceed : DTS ignore la vérification des noms en double. Avertissement Cela peut entraîner des incohérences de données : si les schémas correspondent, les enregistrements source écrasent les enregistrements de destination ayant la même clé primaire ; si les schémas diffèrent, la migration peut échouer ou produire des données incomplètes. À utiliser avec prudence.
Capitalization of Object Names in Destination Instance	Contrôle la casse des noms de bases de données, de tables et de colonnes dans la destination. La valeur par défaut est DTS default policy. Consultez Spécifier la casse des noms d'objets dans l'instance de destination.
Source Objects	Sélectionnez les objets à migrer. Cliquez sur l'icône pour les déplacer vers Selected Objects. La granularité des objets de migration peut être le schéma, la table ou la colonne.
Selected Objects	- Pour mapper un objet vers un nom ou une destination différente, faites un clic droit sur l'objet et sélectionnez l'option de mappage. Consultez Mapper les noms d'objets. <br>- Pour supprimer un objet, cliquez dessus puis cliquez sur l'icône . <br>- Pour définir le paramètre bucket_count pour une table (disponible lorsque Schema Migration est sélectionné et que la granularité de l'objet de migration est la table) : faites un clic droit sur la table, définissez Enable Parameter Settings sur Yesparamètres de notification d'alerte, saisissez la valeur, puis cliquez sur OK. <br>- Pour filtrer les lignes selon des conditions SQL, faites un clic droit sur une table et spécifiez les conditions. Consultez Spécifier les conditions de filtrage. <br>- Pour sélectionner les opérations SQL à migrer de manière incrémentielle, faites un clic droit sur un objet et sélectionnez les opérations.

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

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

Étape 6 : Configurer les champs de base de données et de tables (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 n'est disponible que lorsque Schema Migration est sélectionné. Pour afficher toutes les tables, définissez Definition Status sur All .

La Primary Key Column peut être une clé primaire composite. Sélectionnez une ou plusieurs colonnes dans Primary Key Column à utiliser comme Distribution Key .

Pour les tables sans clé primaire ni contrainte UNIQUE, définissez Engine sur duplicate , sinon la migration risque d'échouer ou des données peuvent être perdues.

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

Cliquez sur Next: Save Task Settings and Precheck.

Pour prévisualiser les paramètres API permettant de configurer cette tâche, survolez Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters avant de continuer.

DTS exécute une pré-vérification avant de lancer la migration. Si la pré-vérification échoue :

• Pour les éléments en échec : cliquez sur View Details, analysez les résultats, résolvez les problèmes, puis cliquez sur Precheck Again.

• Pour les éléments d'alerte : si l'alerte peut être ignorée, cliquez sur Confirm Alert Details > Ignore > OK > Precheck Again. Notez qu'ignorer des alertes peut entraîner des incohérences de données.

Étape 8 : Acheter 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 :

   Section	Paramètre	Description
   New Instance Class	Resource Group	Groupe de ressources pour l'instance de migration. Valeur par défaut : default resource group. Consultez Qu'est-ce que Resource Management ?.
   	Instance Class	La classe d'instance détermine la vitesse de migration. Consultez Classes d'instances de migration de données.

3. Lisez et cochez la case Data Transmission Service (Pay-as-you-go) Service Terms.

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

Suivez la progression sur la page Data Migration :

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

• Migration incrémentielle incluse : la tâche s'exécute en continu et ne s'arrête jamais automatiquement. Le statut affiche Running.

Lors de la migration complète des données, DTS consomme des ressources de lecture et d'écriture sur les bases de données source et de destination, ce qui augmente la charge de la base de données. Effectuez la migration en dehors des heures de pointe, lorsque la charge CPU des deux bases de données est inférieure à 30 %.

Latence de la migration incrémentielle

DTS utilise une politique de synchronisation par lots pour réduire la charge sur la destination. Par défaut, chaque objet de synchronisation est écrit au maximum une fois toutes les 5 secondes, ce qui donne une latence de synchronisation normale généralement inférieure à 10 secondes.

Pour réduire la latence, ajustez le paramètre selectdb.reservoir.timeout.milliseconds de l'instance de migration dans la console DTS. La plage valide est de 1 000 à 10 000 millisecondes.

Un temps de traitement par lots plus court augmente la fréquence d'écriture, ce qui accroît la charge et le temps de réponse sur la destination. Cela peut à son tour augmenter la latence de synchronisation. Ajustez ce paramètre en fonction de la charge réelle de la destination.

Récupération après défaillance de l'instance

Si une instance de migration tombe en panne, le support DTS tentera de la récupérer dans un délai de 8 heures. Pendant la récupération, l'instance peut être redémarrée ou ses paramètres ajustés (seuls les paramètres de l'instance DTS sont modifiés, les paramètres de la base de données ne sont pas changés). Pour la liste des paramètres susceptibles d'être modifiés, consultez Modifier les paramètres de l'instance.

Migration en dehors des heures de pointe

Effectuez la migration en dehors des heures de pointe, lorsque la charge CPU des bases de données source et de destination est inférieure à 30 %. Cela réduit le risque de dégradation des performances des charges de travail en production.