Type
Description
Limites de la base de données source
Les tables sélectionnées pour la migration doivent disposer d'une clé primaire ou d'une contrainte d'unicité, et les champs inclus dans cette contrainte doivent être uniques. À défaut, des données en double peuvent apparaître dans la base de données de destination.
Si la table de destination n'a pas été créée par Data Transmission Service (DTS) parce que vous n'avez pas sélectionné Schema Migration comme Migration Types, vous devez vous assurer que la table de destination possède la même clé primaire ou la même contrainte d'unicité non nulle que la table source. Sinon, des données en double risquent d'apparaître dans la base de données de destination.
Le nom de la base de données à migrer ne doit pas contenir de tirets (-), par exemple dts-testdata.
Si vous sélectionnez des tables comme objets de migration et que vous devez les modifier (par exemple, en mappant les noms de tables ou de colonnes), une seule tâche de migration peut traiter jusqu'à 1 000 tables. Le dépassement de cette limite provoque une erreur lors de la soumission de la tâche. Dans ce cas, répartissez les tables sur plusieurs tâches ou configurez une tâche pour migrer la base de données entière.
DTS ne migre pas les tables temporaires, les déclencheurs internes ni certaines fonctions (telles que les fonctions en langage C et les fonctions internes pour PROCEDURE et FUNCTION) depuis la base de données source. DTS prend en charge la migration de certains types de données personnalisés (COMPOSITE, ENUM ou RANGE) ainsi que les contraintes suivantes : clé primaire, clé étrangère, unicité et CHECK.
Pour une migration incrémentielle des données, les exigences suivantes s'appliquent aux journaux de transactions anticipées (WAL) :
Le paramètre wal_level doit être défini sur logical.
Pour une tâche de migration incrémentielle des données, les WAL de la base de données source doivent être conservés pendant plus de 24 heures. Pour une tâche incluant à la fois la migration complète et la migration incrémentielle des données, DTS exige que les WAL soient conservés pendant au moins 7 jours. Une fois la migration complète des données terminée, vous pouvez réduire la période de conservation à plus de 24 heures. Si DTS ne parvient pas à obtenir les WAL requis, la tâche de migration peut échouer. Dans les cas extrêmes, cela peut entraîner une incohérence ou une perte de données. Les problèmes causés par une période de conservation des WAL inférieure à la durée requise ne sont pas couverts par l'accord de niveau de service (SLA) de DTS.
Limites relatives aux opérations dans la base de données source :
Pendant les phases de migration du schéma et de migration complète des données, n'effectuez pas d'opérations DDL, car elles entraîneraient l'échec de la tâche de migration.
Si vous effectuez uniquement une migration complète des données, n'écrivez pas de nouvelles données dans la base de données source. Cela provoquerait une incohérence des données entre les bases de données source et de destination. Pour garantir la cohérence des données en temps réel, sélectionnez un type de migration qui inclut la migration du schéma, la migration complète des données et la migration incrémentielle des données.
En raison des limitations des abonnements logiques, si une instance de migration incluant une migration incrémentielle des données est en cours d'exécution et que la taille d'une seule ligne à migrer dépasse 256 Mo après une modification incrémentielle, l'instance de migration échoue de manière irrécupérable et vous devez la reconfigurer.
Si la base de données source contient des transactions de longue durée et que l'instance est configurée pour une tâche de migration incrémentielle, les journaux de transactions anticipées (WAL) générés avant la validation des transactions ne peuvent pas être supprimés. Cela peut entraîner une accumulation des WAL et épuiser l'espace disque de la base de données source.
Si vous effectuez une mise à niveau majeure de la base de données source pendant qu'une instance de migration est en cours d'exécution, l'instance échoue de manière irrécupérable et vous devez la reconfigurer.
Les tables contenant des colonnes générées dans PostgreSQL 18 ne prennent pas en charge la migration. Si vous configurez la migration pour de telles tables, les opérations DML sur ces tables seront bloquées.
Autres limites
Pour éviter les interruptions d'abonnement logique causées par un basculement et garantir la stabilité de la tâche de migration des données, vous devez activer le basculement des emplacements de réplication logique (Logical Replication Slot Failover) pour votre instance ApsaraDB RDS for PostgreSQL. Pour obtenir des instructions, consultez Logical Replication Slot Failover.
DTS migre une seule base de données par tâche. Pour migrer plusieurs bases de données, configurez une tâche distincte pour chacune d'elles.
DTS ne prend pas en charge la migration des tables d'extension TimescaleDB, des tables avec héritage inter-schémas ni des tables avec des index uniques basés sur des expressions.
Les schémas créés par des plug-ins ne peuvent pas être migrés et ne sont pas disponibles pour la sélection dans la console lors de la configuration de la tâche.
Si une table à migrer contient une colonne de type SERIAL, une séquence est automatiquement créée pour cette colonne dans la base de données source. Par conséquent, lorsque vous configurez les Source Objects, si les Migration Types incluent Schema Migration, nous vous recommandons de sélectionner également Sequence ou de migrer le schéma entier. À défaut, l'instance de migration risque d'échouer.
Lorsque DTS migre des données entre des bases de données PostgreSQL, ni la liaison de propriété OWNED BY d'une séquence ni la valeur actuelle de la séquence ne sont migrées vers la base de données de destination. Avant de basculer vos charges de travail, vous devez effectuer les opérations suivantes dans la base de données de destination :
Reconstruire la liaison de propriété : exécutez la commande ALTER SEQUENCE pour lier à nouveau la séquence à sa colonne. Par exemple : ALTER SEQUENCE order_id_seq OWNED BY orders.order_id;.
Définir la valeur actuelle : exécutez la fonction setval() pour définir la séquence sur la valeur réelle de la base de données source. Par exemple : SELECT setval('order_id_seq', 100, true);.
Pour les tâches incluant une migration incrémentielle des données, vous devez exécuter la commande ALTER TABLE schema.table REPLICA IDENTITY FULL; sur les tables à migrer dans la base de données source avant d'y écrire des données. Cela garantit la cohérence des données pour les tables dans les deux scénarios suivants. Pour éviter les interblocages, évitez les opérations de verrouillage de table pendant l'exécution de cette commande. Si vous ignorez les vérifications associées lors de la pré-vérification, DTS exécute automatiquement cette commande lors de l'initialisation de l'instance.
Lors du premier démarrage de l'instance.
Lorsque la granularité de l'objet de migration est définie sur Schéma et qu'une nouvelle table est créée dans le schéma ou qu'une table existante est reconstruite à l'aide de la commande RENAME.
Dans la commande, remplacez schema et table par le nom du schéma et le nom de la table des données à migrer.
Effectuez cette opération pendant les heures creuses.
DTS valide le contenu des données mais pas les métadonnées telles que les séquences ; vous devez valider les métadonnées vous-même.
Après avoir basculé vos charges de travail vers l'instance de destination, les nouvelles séquences écrites n'incrémentent pas à partir de la valeur maximale des séquences correspondantes dans la base de données source. Avant de basculer vos charges de travail, vous devez mettre à jour les valeurs des séquences dans la base de données de destination. Pour plus d'informations, consultez Update sequence values in the destination database.
Lorsque DTS migre des séquences, il ne migre ni la relation OWNED BY ni la valeur actuelle de chaque séquence. Après la migration, les séquences existent dans la base de données de destination, mais la relation OWNED BY est vide et last_value peut être null ou correspondre à la valeur initiale. Avant de basculer vos charges de travail vers la base de données de destination, reconstruisez manuellement la relation OWNED BY et définissez la valeur actuelle de chaque séquence dans la base de données de destination. Exécutez l'instruction suivante dans la base de données de destination pour reconstruire la relation OWNED BY. Remplacez <schema>, <sequence_name>, <table> et <column> par le nom du schéma, le nom de la séquence, le nom de la table et le nom de la colonne réels.
ALTER SEQUENCE <schema>.<sequence_name> OWNED BY <schema>.<table>.<column>;
Exécutez l'instruction suivante dans la base de données de destination pour définir la valeur actuelle de la séquence sur la même valeur que celle de la base de données source. Remplacez <current_value> par la valeur last_value de la séquence dans la base de données source.
SELECT setval('<schema>.<sequence_name>', <current_value>, true);
Vous pouvez exécuter l'instruction SQL suivante dans la base de données source pour interroger les informations sur les séquences par lots, y compris la relation OWNED BY, last_value et les instructions pouvant être exécutées dans la base de données de destination.
SELECT
seq_ns.nspname AS sequence_schema,
seq.relname AS sequence_name,
tbl_ns.nspname AS table_schema,
tbl.relname AS table_name,
attr.attname AS column_name,
ps.last_value,
CASE
WHEN tbl.oid IS NOT NULL AND attr.attname IS NOT NULL THEN
format(
'ALTER SEQUENCE %I.%I OWNED BY %I.%I.%I;',
seq_ns.nspname,
seq.relname,
tbl_ns.nspname,
tbl.relname,
attr.attname
)
END AS alter_sequence_sql,
CASE
WHEN ps.last_value IS NOT NULL THEN
format(
'SELECT setval(%L, %s, true);',
format('%I.%I', seq_ns.nspname, seq.relname),
ps.last_value
)
END AS setval_sql
FROM pg_class seq
JOIN pg_namespace seq_ns ON seq.relnamespace = seq_ns.oid
LEFT JOIN pg_depend dep
ON dep.objid = seq.oid
AND dep.deptype = 'a'
LEFT JOIN pg_class tbl ON dep.refobjid = tbl.oid
LEFT JOIN pg_namespace tbl_ns ON tbl.relnamespace = tbl_ns.oid
LEFT JOIN pg_attribute attr
ON attr.attrelid = tbl.oid
AND attr.attnum = dep.refobjsubid
LEFT JOIN pg_sequences ps
ON ps.schemaname = seq_ns.nspname
AND ps.sequencename = seq.relname
WHERE seq.relkind = 'S'
ORDER BY sequence_schema, sequence_name;
DTS crée les tables temporaires suivantes dans la base de données source pour obtenir des informations telles que les instructions DDL pour les données incrémentielles, les schémas des tables incrémentielles et les données de pulsation. Ne supprimez pas ces tables temporaires pendant la migration. Sinon, la tâche DTS sera interrompue. DTS supprime automatiquement ces tables 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.
Cette limite s'applique aux tâches de migration complète ou incrémentielle des données où les tables à migrer depuis la base de données source contiennent des clés étrangères, des déclencheurs ou des déclencheurs d'événements. DTS définit temporairement le paramètre session_replication_role sur replica au niveau de la session pendant la migration. Si le compte de la base de données de destination ne dispose pas des autorisations requises, vous devez définir manuellement le paramètre sur replica dans la base de données de destination. Pendant cette période (lorsque session_replication_role est défini sur replica), les opérations de mise à jour ou de suppression en cascade dans la base de données source peuvent provoquer une incohérence des données. Une fois la tâche de migration libérée, vous pouvez redéfinir le paramètre sur origin.
Pour garantir l'exactitude de la latence affichée pour la migration incrémentielle des données, DTS crée une table de pulsation nommée dts_postgres_heartbeat dans la base de données source.
Pendant la migration incrémentielle des données, DTS crée un emplacement de réplication préfixé par dts_sync_ dans la base de données source pour répliquer les données. Cet emplacement de réplication permet à DTS d'obtenir les journaux incrémentiels de la base de données source à partir des 15 dernières minutes. Lorsqu'une tâche de migration des données échoue ou que l'instance de migration est libérée, DTS tente de nettoyer automatiquement l'emplacement de réplication.
Si vous modifiez le mot de passe du compte de la base de données source utilisé par la tâche ou si vous supprimez les adresses IP de DTS de la liste d'autorisation d'adresses IP de la base de données source pendant la migration, l'emplacement de réplication ne peut pas être nettoyé automatiquement. Dans ce cas, vous devez nettoyer manuellement l'emplacement de réplication dans la base de données source pour éviter l'accumulation de journaux, qui pourrait épuiser l'espace disque et rendre la base de données source indisponible.
Si un basculement principal/secondaire se produit sur la base de données source, vous devez vous connecter à la base de données secondaire pour nettoyer manuellement l'emplacement de réplication.
Avant de migrer les données, évaluez les performances des bases de données source et de destination. Effectuez la migration des données pendant les heures creuses. Pendant 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 peut augmenter la charge de la base de données.
La migration complète des données implique des opérations INSERT concurrentes, ce qui peut provoquer une fragmentation des tables dans la base de données de destination, entraînant une consommation d'espace de stockage supérieure à celle de la source.
Vérifiez si la précision de migration pour les colonnes de type FLOAT ou DOUBLE répond à vos besoins métier. DTS utilise la fonction ROUND(COLUMN,PRECISION) pour lire les valeurs de ces colonnes. Si vous ne définissez pas explicitement une précision, DTS utilise une précision de 38 chiffres pour FLOAT et de 308 chiffres pour DOUBLE.
DTS tente de reprendre une tâche de migration ayant échoué pendant sept jours maximum. Par conséquent, avant de basculer vos charges de travail vers l'instance de destination, vous devez arrêter ou libérer la tâche. Vous pouvez également révoquer les autorisations d'écriture du compte utilisé par DTS pour accéder à l'instance de destination à l'aide de la commande REVOKE. Cela empêche une tâche reprise automatiquement d'écraser les données dans l'instance de destination.
Si une tâche échoue, l'équipe d'assistance DTS tentera de la restaurer dans un délai de huit heures. Lors de la restauration, elle peut redémarrer la tâche ou ajuster ses paramètres.
Seuls les paramètres de la tâche DTS sont modifiés, pas les paramètres de la base de données. Les paramètres susceptibles d'être ajustés incluent ceux répertoriés dans Modify instance parameters.
Lorsque vous migrez une table partitionnée, vous devez inclure à la fois la table parente et ses partitions enfants comme objets de migration. À défaut, les données de la table partitionnée pourraient devenir incohérentes.
La table parente d'une table partitionnée PostgreSQL ne stocke pas directement les données. Toutes les données sont stockées dans ses partitions enfants. Une tâche de migration des données doit inclure la table parente et toutes ses partitions enfants. À défaut, les données des partitions enfants pourraient être omises, ce qui entraînerait une incohérence des données entre la source et la destination.
La migration de tables partitionnées et de tables d'héritage (tables parent-enfant) entre différentes bases de données n'est pas prise en charge. Assurez-vous que la table partitionnée et toutes ses partitions se trouvent dans la même base de données. Assurez-vous également que la table parente et toutes ses tables enfants se trouvent dans la même base de données.
Cas particuliers
Ne modifiez pas le point de terminaison de connexion ni la zone d'une instance source ApsaraDB RDS for PostgreSQL pendant la migration, car cela entraînerait l'échec de la tâche.
Cette rubrique explique comment utiliser Data Transmission Service (DTS) pour la migration du schéma, la migration complète des données et la migration incrémentielle des données entre des instances ApsaraDB RDS for PostgreSQL. En combinant ces trois types de migration, vous pouvez migrer votre base de données sans interruption de service.
Prérequis
-
Vous avez créé les instances source et de destination ApsaraDB RDS for PostgreSQL. Pour plus d'informations, consultez Créer une instance ApsaraDB RDS for PostgreSQL.
RemarquePour connaître les versions prises en charge des bases de données source et de destination, consultez Présentation des scénarios de migration.
Pour garantir la compatibilité, la base de données de destination doit exécuter la même version ou une version ultérieure à celle de la base de données source. La migration des données vers une version antérieure peut provoquer des problèmes de compatibilité.
L'instance ApsaraDB RDS for PostgreSQL de destination doit disposer de plus d'espace de stockage que celui utilisé par l'instance ApsaraDB RDS for PostgreSQL source.
Types de migration
-
Migration du schéma
DTS migre les définitions de schéma des objets de migration de la base de données source vers la base de données de destination.
-
Migration complète
DTS migre toutes les données historiques des objets de migration spécifiés de la base de données source vers la base de données de destination.
-
Migration incrémentielle
Une fois la migration complète terminée, DTS migre les mises à jour incrémentielles des données de la base de données source vers la base de données de destination. La migration incrémentielle vous permet de migrer les données en toute transparence sans interrompre vos applications autogérées.
Procédure
-
Accédez à la page de liste des tâches de migration pour la région de destination en utilisant l'une des méthodes suivantes.
Depuis la console DTS
Depuis la console DMS
RemarqueLes opérations réelles peuvent varier selon le mode et la disposition de la console DMS. Pour plus d'informations, consultez les rubriques Console en mode simple et Personnaliser la disposition et le style de la console DMS.
Cliquez sur Create Task pour accéder à la page de configuration de la tâche.
-
Configurez les bases de données source et de destination.
AvertissementAprès avoir sélectionné les instances source et de destination, nous vous recommandons de lire attentivement les limites affichées en haut de la page. Dans le cas contraire, la tâche pourrait échouer ou entraîner une incohérence des données.
Section
Parameter
Description
N/A
Task Name
DTS génère automatiquement un nom de tâche. Nous vous recommandons de spécifier un nom descriptif pour faciliter l'identification. Le nom n'a pas besoin d'être unique.
Source Database
Select Existing Connection
Pour utiliser une instance de base de données qui a été ajoutée au système (créée ou enregistrée), sélectionnez l'instance de base de données souhaitée dans la liste déroulante. Les informations de base de données ci-dessous seront configurées automatiquement.
RemarqueDans la console DMS, ce paramètre est nommé Select a DMS database instance..
Si vous n'avez pas enregistré l'instance de base de données auprès du système ou si vous n'avez pas besoin d'utiliser une instance enregistrée, configurez manuellement les informations de base de données ci-dessous.
Database Type
Sélectionnez PostgreSQL.
Access Method
Sélectionnez Alibaba Cloud Instance.
Instance Region
Sélectionnez la région où se trouve l'instance ApsaraDB RDS for PostgreSQL source.
Instance ID
Sélectionnez l'ID de l'instance ApsaraDB RDS for PostgreSQL source.
Database Name
Saisissez le nom de la base de données dans l'instance ApsaraDB RDS for PostgreSQL source qui contient les objets à migrer.
Database Account
Saisissez le compte de base de données pour l'instance ApsaraDB RDS for PostgreSQL source. Pour plus d'informations sur les autorisations requises, consultez la section Autorisations requises pour les comptes de base de données.
Database Password
Saisissez le mot de passe du compte de base de données.
Encryption
Indique s'il faut chiffrer la connexion à la base de données source. Vous pouvez configurer ce paramètre en fonction de vos besoins métier. Dans cet exemple, l'option Non-encrypted est sélectionnée.
Si vous souhaitez établir une connexion chiffrée SSL avec la base de données source, procédez comme suit : sélectionnez SSL-encrypted, téléchargez le CA Certificate, le Client Certificate et la Private Key of Client Certificate selon vos besoins, puis spécifiez le Private Key Password of Client Certificate.
Remarque-
Si vous définissez le chiffrement sur SSL-encrypted pour une base de données PostgreSQL autogérée, vous devez télécharger le CA Certificate.
-
Si vous souhaitez utiliser le certificat client, vous devez télécharger le Client Certificate et la Private Key of Client Certificate et spécifier le Private Key Password of Client Certificate.
-
Pour savoir comment configurer le chiffrement SSL pour une instance ApsaraDB RDS for PostgreSQL, consultez la rubrique Chiffrement SSL.
Destination Database
Select Existing Connection
Pour utiliser une instance de base de données qui a été ajoutée au système (créée ou enregistrée), sélectionnez l'instance de base de données souhaitée dans la liste déroulante. Les informations de base de données ci-dessous seront configurées automatiquement.
RemarqueDans la console DMS, ce paramètre est nommé Select a DMS database instance..
Si vous n'avez pas enregistré l'instance de base de données auprès du système ou si vous n'avez pas besoin d'utiliser une instance enregistrée, configurez manuellement les informations de base de données ci-dessous.
Database Type
Sélectionnez PostgreSQL.
Access Method
Sélectionnez Alibaba Cloud Instance.
Instance Region
Sélectionnez la région où se trouve l'instance ApsaraDB RDS for PostgreSQL de destination.
Instance ID
Sélectionnez l'ID de l'instance ApsaraDB RDS for PostgreSQL de destination.
Database Name
Saisissez le nom de la base de données dans l'instance ApsaraDB RDS for PostgreSQL de destination qui recevra les objets migrés.
Database Account
Saisissez le compte de base de données pour l'instance ApsaraDB RDS for PostgreSQL de destination. Pour plus d'informations sur les autorisations requises, consultez la section Autorisations requises pour les comptes de base de données.
Database Password
Saisissez le mot de passe du compte de base de données.
Encryption
Indique s'il faut chiffrer la connexion à la base de données source. Vous pouvez configurer ce paramètre en fonction de vos besoins métier. Dans cet exemple, l'option Non-encrypted est sélectionnée.
Si vous souhaitez établir une connexion chiffrée SSL avec la base de données source, procédez comme suit : sélectionnez SSL-encrypted, téléchargez le CA Certificate, le Client Certificate et la Private Key of Client Certificate selon vos besoins, puis spécifiez le Private Key Password of Client Certificate.
Remarque-
Si vous définissez le chiffrement sur SSL-encrypted pour une base de données PostgreSQL autogérée, vous devez télécharger le CA Certificate.
-
Si vous souhaitez utiliser le certificat client, vous devez télécharger le Client Certificate et la Private Key of Client Certificate et spécifier le Private Key Password of Client Certificate.
-
Pour savoir comment configurer le chiffrement SSL pour une instance ApsaraDB RDS for PostgreSQL, consultez la rubrique Chiffrement SSL.
-
Une fois la configuration terminée, cliquez sur Test Connectivity and Proceed en bas de la page.
RemarqueAssurez-vous que les blocs CIDR des adresses IP des serveurs DTS sont ajoutés aux paramètres de sécurité des bases de données source et de destination pour autoriser l'accès depuis les serveurs DTS. Cette opération peut être effectuée automatiquement ou manuellement. Pour plus d'informations, consultez la rubrique Ajouter les blocs CIDR des adresses IP des serveurs DTS à une liste d'autorisation.
Si la base de données source ou de destination est une base de données autogérée (où la Access Method n'est pas Alibaba Cloud Instance), vous devez également cliquer sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers.
-
Configurez les objets de la tâche.
Lorsque le Success Rate atteint 100 %, cliquez sur Next: Purchase Instance.
-
Sur la page Purchase, sélectionnez la spécification de lien pour l'instance de migration de données. Pour plus d'informations, consultez le tableau suivant.
Catégorie
Paramètre
Description
New Instance Class
Resource Group Settings
Sélectionnez le groupe de ressources auquel l'instance appartient. La valeur par défaut est le groupe de ressources par défaut. Pour plus d'informations, consultez la rubrique Qu'est-ce que la gestion des ressources ?
Instance Class
DTS propose des spécifications de migration avec différents niveaux de performance. La spécification de lien affecte la vitesse de migration. Vous pouvez sélectionner une spécification en fonction de votre scénario métier. Pour plus d'informations, consultez la rubrique Spécifications de lien de migration de données.
Une fois la configuration terminée, lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms.
-
Cliquez sur Buy and Start. Dans la boîte de dialogue OK qui s'affiche, cliquez sur OK.
Vous pouvez consulter la progression de la tâche de migration sur la page de liste Data Migration Tasks.
RemarqueSi la tâche de migration n'inclut pas de migration incrémentielle, elle s'arrête automatiquement une fois la migration complète terminée. Une fois la tâche arrêtée, son Status passe à Completed.
Si la tâche de migration inclut une migration incrémentielle, elle ne s'arrête pas automatiquement. La tâche de migration incrémentielle continue de s'exécuter. Pendant l'exécution de la tâche de migration incrémentielle, le Status de la tâche est Running.
-
schéma et table
RemarqueCela inclut la clé primaire, la clé unique, la clé étrangère, DATATYPE (type de données intégré) et la contrainte par défaut.
vue, procédure (pour PostgreSQL 11 ou version ultérieure), fonction, règle, séquence, extension, déclencheur, agrégat, index, opérateur et domaine
-
Sur la page Configure Objects, configurez les objets que vous souhaitez migrer.
Parameter
Description
Migration Types
-
Pour effectuer une migration complète unique des données, sélectionnez à la fois Schema Migration et Full Data Migration.
-
Pour réaliser une migration avec un temps d'arrêt minimal, sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration.
Remarque-
Si vous sélectionnez Schema Migration, DTS migre le schéma des tables à migrer, y compris les clés étrangères, de la base de données source vers la base de données de destination.
-
Si vous ne sélectionnez pas Incremental Data Migration, n'écrivez aucune nouvelle donnée dans l'instance source pendant la migration afin de garantir la cohérence des données.
Processing Mode of Conflicting Tables
Precheck and Report Errors : vérifie si des tables portant le même nom existent dans la base de données de destination. Si aucune table homonyme n'existe, la prévalidation est réussie. En revanche, si des tables homonymes existent, une erreur est signalée lors de la prévalidation et la tâche de migration des données ne démarre pas.
RemarqueSi une table de la base de données de destination porte le même nom mais ne peut pas être facilement supprimée ou renommée, vous pouvez modifier le nom de cette table dans la base de données de destination. Pour plus d'informations, consultez la rubrique Object name mapping.
Ignore Errors and Proceed : ignore la vérification des tables homonymes.
AvertissementLa sélection de l'option Ignore Errors and Proceed peut entraîner une incohérence des données et présenter des risques pour votre activité. Par exemple :
Si les schémas de table sont identiques et qu'un enregistrement de la base de données de destination possède la même valeur de clé primaire qu'un enregistrement de la base de données source :
Lors de la migration complète, DTS conserve l'enregistrement présent dans la base de données de destination. L'enregistrement issu de la base de données source n'est pas migré.
Lors de la migration incrémentielle, DTS ne conserve pas l'enregistrement présent dans la base de données de destination. L'enregistrement issu de la base de données source écrase celui de la base de données de destination.
Si les schémas de table sont différents, seule une partie des colonnes de données peut être migrée, ou la migration peut échouer. Agissez avec prudence.
Source Objects
Dans la zone Source Objects, cliquez sur les objets à migrer, puis cliquez sur
pour les déplacer vers la zone Selected Objects.Remarque-
Vous pouvez sélectionner des objets au niveau du schéma ou de la table. Si vous sélectionnez des tables, les autres objets tels que les vues, les déclencheurs et les procédures stockées ne sont pas migrés.
-
Si une table à migrer contient des colonnes de type SERIAL et que vous avez sélectionné Migration Types pour l'option Schema Migration, sélectionnez également Sequence ou migrez l'intégralité du schéma.
Selected Objects
-
Pour modifier le nom d'un seul objet de migration dans l'instance cible, faites un clic droit sur l'objet dans la zone Selected Objects. Pour plus d'informations, consultez la rubrique Map individual schema, table, and column names.
-
Pour modifier les noms de plusieurs objets de migration dans l'instance cible, cliquez sur Selected Objects dans le coin supérieur droit de la zone Batch Edit. Pour plus d'informations, consultez la rubrique Map multiple schema, table, and column names.
Remarque-
Si vous utilisez la fonctionnalité de mappage des noms d'objets, il est possible que les autres objets dépendant de l'objet renommé ne soient pas migrés correctement.
-
Pour définir une clause WHERE afin de filtrer les données, faites un clic droit sur la table dans la zone Selected Objects et spécifiez la condition de filtre dans la boîte de dialogue qui s'affiche. Pour plus d'informations, consultez la rubrique Set filter conditions.
-
Pour sélectionner les opérations SQL incrémentielles à migrer au niveau de la base de données ou de la table, faites un clic droit sur l'objet dans la zone Selected Objects et choisissez les opérations SQL souhaitées dans la boîte de dialogue qui s'affiche.
-
-
Cliquez sur Next: Advanced Settings pour configurer les paramètres avancés.
Parameter
Description
Dedicated Cluster for Task Scheduling
Par défaut, DTS planifie les tâches sur un cluster partagé. Aucune sélection n'est requise. Si vous souhaitez une stabilité accrue pour vos tâches, vous pouvez acheter un dedicated cluster pour exécuter les tâches de migration DTS.
Retry Time for Failed Connections
Une fois la tâche de migration démarrée, si la connexion à la base de données source ou de destination échoue, DTS signale une erreur et tente immédiatement de rétablir la connexion. La durée de nouvelle tentative par défaut est de 720 minutes. Vous pouvez personnaliser cette durée entre 10 et 1 440 minutes. Nous vous recommandons de définir une durée supérieure à 30 minutes. Si DTS parvient à se reconnecter aux bases de données source et de destination dans le délai imparti, la tâche de migration reprend automatiquement. Dans le cas contraire, la tâche échoue.
RemarquePour plusieurs instances DTS partageant la même source ou la même destination, le délai de nouvelle tentative réseau est déterminé par le paramétrage de la dernière tâche créée.
Étant donné que la tâche est facturée pendant la période de nouvelle tentative de connexion, nous vous conseillons de personnaliser le délai de nouvelle tentative en fonction de vos besoins métier, ou de libérer l'instance DTS dès que possible après la libération des instances de base de données source et de destination.
Retry Time for Other Issues
Une fois la tâche de migration démarrée, si un problème autre qu'un problème de connectivité survient dans la base de données source ou de destination (par exemple, une exception lors de l'exécution d'une instruction DDL ou DML), DTS signale une erreur et tente immédiatement de relancer l'opération. La durée de nouvelle tentative par défaut est de 10 minutes. Vous pouvez personnaliser cette durée entre 1 et 1 440 minutes. Nous vous recommandons de définir une durée supérieure à 10 minutes. Si les opérations concernées aboutissent dans le délai de nouvelle tentative spécifié, la tâche de migration reprend automatiquement. Dans le cas contraire, la tâche échoue.
ImportantLa valeur définie pour Retry Time for Other Issues doit être inférieure à celle définie pour Retry Time for Failed Connections.
Enable Throttling for Full Data Migration
Lors de la migration complète, DTS consomme des ressources de lecture et d'écriture sur les bases de données source et de destination, ce qui peut augmenter la charge de la base de données. Si nécessaire, vous pouvez activer la limitation du débit pour la tâche de migration complète. Vous pouvez définir les paramètres Queries per second (QPS) to the source database, RPS of Full Data Migration et Data migration speed for full migration (MB/s) afin de réduire la charge sur la base de données de destination.
RemarqueCet élément de configuration est disponible uniquement si vous sélectionnez l'option Full Data Migration pour Migration Types.
Vous pouvez également ajuster la vitesse de migration complète une fois que l'instance de migration est en cours d'exécution.
Enable Throttling for Incremental Data Migration
Si nécessaire, vous pouvez également définir des limites de vitesse pour la tâche de migration incrémentielle. Vous pouvez configurer les paramètres RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s) afin de réduire la charge sur la base de données de destination.
RemarqueCet élément de configuration est disponible uniquement si vous sélectionnez l'option Incremental Data Migration pour Migration Types.
Vous pouvez également ajuster la vitesse de migration incrémentielle une fois que l'instance de migration est en cours d'exécution.
Environment Tag
Vous pouvez sélectionner un tag d'environnement pour identifier l'instance selon vos besoins métier. Cet exemple ne nécessite aucun tag d'environnement.
Configure ETL
Choisissez d'activer ou non la fonctionnalité ETL (Extract, Transform, Load). Pour plus d'informations, consultez la rubrique What is ETL? Valeurs valides :
-
Yes : active la fonctionnalité ETL. Saisissez les instructions de traitement des données dans l'éditeur de code. Pour plus d'informations, consultez la rubrique Configure ETL in a data migration or data synchronization task.
-
No : désactive la fonctionnalité ETL.
Monitoring and Alerting
Sélectionnez l'option permettant de configurer des alertes et de recevoir des notifications d'alerte en fonction de vos besoins métier.
No : ne configure aucune alerte.
Yes : configurez les alertes en définissant un seuil d'alerte et des notifications d'alerte. Si une migration échoue ou si la latence dépasse le seuil défini, le système envoie une notification d'alerte.
-
Cliquez sur Next: Data Validation pour configurer une tâche de validation des données.
Pour plus d'informations sur la fonctionnalité de validation des données, consultez la rubrique Configurer la validation des données.
-
Enregistrez la tâche et exécutez une prévalidation.
Pour afficher les paramètres de configuration de cette instance lors de l'appel de l'opération API, placez le pointeur de la souris sur le bouton Next: Save Task Settings and Precheck et cliquez sur Preview OpenAPI parameters dans la bulle qui s'affiche.
Si vous n'avez pas besoin d'afficher les paramètres de l'API ou si vous avez terminé leur consultation, cliquez sur Next: Save Task Settings and Precheck en bas de la page.
RemarqueAvant le démarrage de la tâche de migration, DTS effectue une prévalidation. La tâche ne démarre qu'après réussite de cette prévalidation.
Si la prévalidation échoue, cliquez sur View Details à côté de l'élément de vérification ayant échoué, corrigez le problème selon les instructions affichées, puis relancez la prévalidation.
-
Si un avertissement est signalé lors de la prévalidation :
Pour les éléments de vérification qui ne peuvent pas être ignorés, cliquez sur Data Migration Tasks à côté de l'élément ayant échoué, corrigez le problème selon les instructions affichées, puis relancez la prévalidation.
Pour les éléments de vérification qui peuvent être ignorés, vous pouvez cliquer sur Confirm Alert Details, Ignore, Status et Precheck Again afin d'ignorer l'élément d'avertissement et de relancer la prévalidation. Si vous choisissez d'ignorer un avertissement, cela peut entraîner des problèmes tels qu'une incohérence des données et présenter des risques pour votre activité.
-
Achetez l'instance.
Opérations SQL prises en charge
Type d'opération
Opération SQL
DML
INSERT,UPDATE,DELETEDDL
-
La migration DDL est prise en charge uniquement pour les tâches de migration de données créées après le .
Important-
Pour les tâches de migration de données créées avant le 12 mai 2023 (heure de Singapour), vous devez créer un déclencheur et une fonction dans la base de données source afin de capturer les informations DDL avant de configurer la tâche. Pour plus d'informations, consultez la rubrique Utiliser des déclencheurs et des fonctions pour implémenter la migration DDL incrémentielle pour PostgreSQL.
-
Le type de données
BITn'est pas pris en charge lors de la migration incrémentielle des données.
-
-
La tâche de migration prend en charge les opérations DDL suivantes, à condition que le compte de la base de données source dispose de privilèges élevés et que l'instance RDS PostgreSQL utilise une version mineure du moteur 20210228 ou ultérieure. Pour savoir comment mettre à niveau la version mineure du moteur, consultez la rubrique Mettre à niveau la version mineure du moteur.
-
CREATE TABLE,DROP TABLE -
ALTER TABLE(y comprisRENAME TABLE,ADD COLUMN,ADD COLUMN DEFAULT,ALTER COLUMN TYPE,DROP COLUMN,ADD CONSTRAINT,ADD CONSTRAINT CHECKetALTER COLUMN DROP DEFAULT) -
TRUNCATE TABLE(nécessite que la base de données source soit PostgreSQL 11 ou une version ultérieure) -
CREATE INDEX ON TABLE
Important-
Les instructions DDL incluant des informations supplémentaires, telles que
CASCADEouRESTRICT, ne sont pas prises en charge. -
Les instructions DDL exécutées dans une session utilisant la commande
SET session_replication_role = replicane sont pas migrées. -
Les instructions DDL exécutées en appelant une
FUNCTIONne sont pas prises en charge. -
Si une validation (commit) contient à la fois des opérations DML et DDL, les opérations DDL ne sont pas migrées.
-
Si une validation (commit) contient des opérations DDL sur des objets qui ne font pas l'objet d'une migration, ces opérations ne sont pas migrées.
-
Les instructions DDL exécutées directement au sein d'un plugin via l'interface SPI (Server Programming Interface) ne sont pas prises en charge.
-
Autorisations des comptes de base de données
Instance de base de données
Migration du schéma
Migration complète des données
Migration incrémentielle des données
Instance ApsaraDB RDS for PostgreSQL source
L'autorisation USAGE sur le schéma
pg_catalog.L'autorisation SELECT sur les objets à migrer.
Un compte privilégié propriétaire de la base de données sélectionnée.
RemarqueSi l'instance ApsaraDB RDS for PostgreSQL source exécute PostgreSQL 9.4 et que vous devez migrer uniquement les opérations DML, le compte a seulement besoin de l'autorisation REPLICATION.
Instance ApsaraDB RDS for PostgreSQL de destination
Les autorisations CREATE et USAGE sur les objets de destination.
Autorisations de propriétaire du schéma.
Pour créer un compte de base de données pour une instance ApsaraDB RDS for PostgreSQL et lui accorder des autorisations, consultez les rubriques Créer un compte et Créer une base de données.
-