Migrez des données entre des instances ApsaraDB RDS for PostgreSQL en utilisant Data Transmission Service (DTS). DTS prend en charge la migration de schéma, la migration complète des données et la migration incrémentielle des données. L'exécution simultanée de ces trois types de migration permet à votre application de rester en ligne tout au long du processus avec un temps d'arrêt minimal.
Prérequis
Avant de commencer, assurez-vous que :
Les instances source et de destination ApsaraDB RDS for PostgreSQL sont créées. Consultez Créer une instance
La version de la base de données de destination est identique ou supérieure à celle de la source. Une version de destination inférieure peut entraîner des problèmes de compatibilité.
L'instance de destination dispose d'un espace de stockage disponible supérieur à la taille totale des données de l'instance source.
Pour connaître les versions de bases de données source et de destination prises en charge, consultez Aperçu des scénarios de migration de données .
Types de migration
DTS propose trois types de migration que vous pouvez combiner selon vos besoins.
| Type de migration | Fonctionnalité |
|---|---|
| Migration de schéma | Copie les schémas des objets sélectionnés (tables, vues, index, etc.) de la source vers la destination. |
| Migration complète des données | Copie toutes les données existantes de la source vers la destination. |
| Migration incrémentielle des données | Réplique continuellement les modifications de données de la source vers la destination une fois la migration complète terminée, maintenant ainsi la synchronisation de la destination pendant l'exécution de votre application. |
Choisissez une stratégie de migration :
Migration complète uniquement (avec temps d'arrêt) : Sélectionnez Schema Migration et Full Data Migration. Arrêtez les écritures sur la source avant le début de la migration pour garantir la cohérence des données.
Migration en ligne (temps d'arrêt minimal) : Sélectionnez Schema Migration, Full Data Migration et Incremental Data Migration. Votre application reste en ligne pendant la migration. N'arrêtez les écritures sur la source qu'au moment du basculement.
Objets pris en charge
Les types d'objets suivants peuvent être migrés :
SCHEMA et TABLE — y compris PRIMARY KEY, UNIQUE KEY, FOREIGN KEY, types de données intégrés et contraintes DEFAULT.
VIEW
PROCEDURE — PostgreSQL V11 ou version ultérieure uniquement.
FUNCTION, RULE, SEQUENCE, EXTENSION, TRIGGER, AGGREGATE, INDEX, OPERATOR, DOMAIN
Opérations SQL prises en charge pour la migration incrémentielle
| Type d'opération | Instructions prises en charge |
|---|---|
| DML | INSERT, UPDATE, DELETE |
| DDL | Voir les détails ci-dessous |
Détails de la migration DDL :
La migration DDL est disponible uniquement pour les tâches créées après le 1er octobre 2020.
Pour migrer les opérations DDL dans les tâches créées avant le 12 mai 2023, créez d'abord un déclencheur et une fonction dans la base de données source. Consultez Utiliser des déclencheurs et des fonctions pour implémenter la migration DDL incrémentielle pour les bases de données PostgreSQL.
Si la base de données source utilise un compte privilégié et que la version mineure du moteur est 20210228 ou ultérieure, les instructions DDL suivantes sont prises en charge :
CREATE TABLE, DROP TABLE
ALTER TABLE (RENAME TABLE, ADD COLUMN, ADD COLUMN DEFAULT, ALTER COLUMN TYPE, DROP COLUMN, ADD CONSTRAINT, ADD CONSTRAINT CHECK, ALTER COLUMN DROP DEFAULT)
TRUNCATE TABLE — la source doit être PostgreSQL V11 ou version ultérieure.
CREATE INDEX ON TABLE
Limitations de la migration DDL :
Les données de type BIT ne peuvent pas être migrées lors de la migration incrémentielle.
Les modificateurs CASCADE et RESTRICT dans les instructions DDL ne peuvent pas être migrés.
Les instructions DDL exécutées dans une session où
SET session_replication_role = replicaa été exécutée ne peuvent pas être migrées.Les instructions DDL invoquées via des fonctions ne peuvent pas être migrées.
Si une soumission par lot contient à la fois des instructions DML et DDL, les instructions DDL sont ignorées.
Si une soumission par lot contient des instructions DDL non prises en charge pour la migration, ces instructions sont ignorées.
Autorisations requises
Accordez les autorisations suivantes aux comptes de base de données utilisés par DTS. Appliquez le principe du moindre privilège : évitez d'utiliser un compte superutilisateur sauf si les autorisations requises ne peuvent pas être accordées séparément.
| Base de données | Migration de schéma | Migration complète des données | Migration incrémentielle des données |
|---|---|---|---|
| Source ApsaraDB RDS for PostgreSQL | USAGE sur le schéma pg_catalog |
SELECT sur les objets à migrer | Compte privilégié propriétaire de la base de données. Pour PostgreSQL 9.4 avec migration DML uniquement, seule l'autorisation REPLICATION est requise. |
| Destination ApsaraDB RDS for PostgreSQL | CREATE et USAGE sur les objets à migrer | Autorisations de propriétaire de schéma | — |
Pour créer des comptes et accorder des autorisations, consultez Créer un compte et Créer une base de données.
Limitations
Examinez ces limitations avant de configurer une tâche de migration. Les ignorer peut entraîner des échecs de tâche ou une incohérence des données.
Limitations de la base de données source
| Limitation | Détails | Impact en cas de non-respect |
|---|---|---|
| Clé primaire ou contrainte unique requise | Les tables doivent avoir des contraintes PRIMARY KEY ou UNIQUE avec tous les champs uniques. Si une table de destination a été créée sans migration de schéma DTS, assurez-vous que sa contrainte PRIMARY KEY ou NOT NULL UNIQUE correspond à celle de la table source. Les tables à migrer doivent également avoir des contraintes PRIMARY KEY, FOREIGN KEY, UNIQUE ou CHECK. | La destination peut contenir des enregistrements en double. |
| Pas de traits d'union dans le nom de la base de données | Le nom de la base de données source ne peut pas contenir de traits d'union (-). Par exemple, dts-testdata n'est pas valide. Renommez la base de données avant la migration. |
La tâche de migration ne démarre pas. |
| Limite de 1 000 tables par tâche lors de la modification des noms de tables | Si vous sélectionnez des tables comme objets de migration et devez renommer des tables ou des colonnes dans la destination, une seule tâche peut migrer jusqu'à 1 000 tables. Pour plus de 1 000 tables, créez plusieurs tâches ou migrez la base de données entière. | Une erreur de requête se produit. |
| Pas de tables temporaires ni de procédures internes en langage C | DTS ne peut pas migrer les tables temporaires, les déclencheurs internes ou les procédures et fonctions internes écrites en C. | Ces objets sont ignorés silencieusement. |
| Prise en charge des types personnalisés | DTS peut migrer les paramètres personnalisés des types COMPOSITE, ENUM et RANGE. | Les autres types personnalisés ne sont pas migrés. |
wal_level doit être défini sur logical pour la migration incrémentielle |
Définissez wal_level = logical dans l'instance source avant de configurer la migration incrémentielle. |
La migration incrémentielle ne peut pas démarrer. |
| Rétention des journaux WAL | Pour la migration incrémentielle uniquement : conservez les journaux de pré-écriture (WAL) pendant plus de 24 heures. Pour la migration complète + incrémentielle : conservez les journaux WAL pendant au moins 7 jours. Une fois la migration complète terminée, vous pouvez réduire la rétention à plus de 24 heures. | Une rétention insuffisante entraîne un échec de la tâche, une incohérence des données ou une perte de données. |
| Pas de DDL pendant la migration de schéma ou la migration complète | N'exécutez pas d'opérations DDL modifiant les schémas de base de données ou de tables pendant l'exécution de la migration de schéma ou de la migration complète des données. | La tâche de migration échoue. |
| Pas d'écritures sur la source pendant la migration complète uniquement | Si vous exécutez uniquement la migration complète des données (sans incrémentiel), n'écrivez pas dans la base de données source pendant la migration. Pour éviter cette restriction, sélectionnez la migration complète + incrémentielle. | Les écritures simultanées provoquent une incohérence des données. |
| Limite de 256 Mo par enregistrement pour la migration incrémentielle | Si une modification incrémentielle unique dépasse 256 Mo, la tâche échoue et ne peut pas être récupérée. Vous devez reconfigurer la tâche. | Échec de la tâche sans option de récupération. |
| Les transactions longues accumulent les journaux WAL | Les transactions longues dans la base de données source empêchent le nettoyage des journaux WAL. Validez ou terminez les transactions longues avant la migration. | L'espace disque de la source peut être épuisé pendant la migration incrémentielle. |
| Les mises à niveau majeures interrompent les tâches en cours | Une mise à niveau majeure de la base de données source pendant l'exécution d'une tâche de migration entraîne l'échec de la tâche sans possibilité de récupération. Reconfigurez la tâche après la mise à niveau. | Échec de la tâche sans option de récupération. |
Autres limitations
| Limitation | Détails |
|---|---|
| Le basculement primaire/secondaire nécessite Logical Replication Slot Failover | Avant d'effectuer un basculement primaire/secondaire sur l'instance source, activez la fonctionnalité Logical Replication Slot Failover. Cela empêche l'interruption des abonnements logiques. Consultez Logical Replication Slot Failover. |
| Une base de données par tâche | Une seule tâche migre les données d'une seule base de données. Créez des tâches distinctes pour chaque base de données. |
| Pas de tables héritées entre schémas | Les tables héritées entre schémas ne peuvent pas être migrées. |
| Le champ SERIAL nécessite la migration de séquence | Si une table possède un champ SERIAL et que vous sélectionnez la migration de schéma, sélectionnez également Sequence ou migrez le schéma entier. Sinon, la tâche échoue. |
| Nouvelles tables créées pendant la migration incrémentielle | Si vous ajoutez une nouvelle table à un schéma ou renommez une table à l'aide de RENAME pendant la migration incrémentielle, exécutez ALTER TABLE schema.table REPLICA IDENTITY FULL; avant d'écrire des données dans cette table. Ne verrouillez pas la table lors de l'exécution de cette instruction pour éviter les interblocages. Exécutez cette opération pendant les heures creuses. |
| Validité des métadonnées non vérifiée | DTS ne valide pas les métadonnées telles que les séquences. Vérifiez manuellement les métadonnées après la migration. |
| Les séquences de destination ne commencent pas à partir du maximum de la source | Après le basculement des charges de travail vers la destination, les nouvelles séquences commencent à partir de leurs valeurs initiales, et non à partir de la valeur maximale de la source. Mettez à jour les valeurs de départ des séquences dans la destination avant le basculement. |
| Tables temporaires créées par DTS | DTS crée les tables temporaires suivantes dans la base de données source pour prendre en charge la migration incrémentielle. Ne les supprimez pas pendant la migration ; elles sont automatiquement supprimées après la libération de l'instance DTS : 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 |
session_replication_role défini sur replica pendant la migration |
Si le compte de destination est un compte privilégié ou possède le rôle superutilisateur, DTS définit session_replication_role sur replica au niveau de la session pendant la migration complète et incrémentielle. Si le compte ne dispose pas de ces autorisations, définissez session_replication_role = replica manuellement. Les opérations CASCADE UPDATE ou DELETE dans la source pendant cette période peuvent provoquer une incohérence des données. Après la libération de la tâche, rétablissez la valeur sur origin. |
| Table de heartbeat créée dans la source | DTS crée une table de heartbeat nommée dts_postgres_heartbeat dans la base de données source pour suivre la latence de la migration incrémentielle. |
| Emplacement de réplication créé dans la source | DTS crée un emplacement de réplication préfixé par dts_sync_ dans la source. Cet emplacement conserve les 15 dernières minutes de journaux incrémentiels. L'emplacement est automatiquement supprimé lorsque l'instance DTS est libérée ou lorsque la tâche échoue. Si vous modifiez le mot de passe de la base de données source ou supprimez les adresses IP de DTS de la liste d'autorisation, supprimez manuellement l'emplacement de réplication pour éviter l'accumulation d'emplacements. Après un basculement primaire/secondaire, connectez-vous à l'instance secondaire pour supprimer l'emplacement. |
| La migration complète provoque une fragmentation des tables | Les opérations INSERT simultanées pendant la migration complète provoquent une fragmentation des tables dans la destination. L'espace de table de destination sera plus grand que celui de la source une fois la migration complète terminée. |
| Précision FLOAT et DOUBLE | DTS utilise ROUND(COLUMN, PRECISION) pour récupérer les valeurs FLOAT et DOUBLE. Si aucune précision n'est spécifiée, FLOAT prend par défaut 38 chiffres et DOUBLE 308 chiffres. Vérifiez que ces paramètres de précision répondent à vos exigences. |
| Les tâches ayant échoué peuvent reprendre et écraser les données de destination | DTS retente une tâche ayant échoué pendant jusqu'à 7 jours. Avant de basculer les charges de travail vers la destination, arrêtez ou libérez les tâches ayant échoué, ou exécutez REVOKE pour supprimer les autorisations d'écriture du compte DTS sur la base de données de destination. |
| Le support DTS peut modifier les paramètres de la tâche | En cas d'échec d'une tâche, l'assistance technique DTS tente de la restaurer dans un délai de 8 heures. La tâche peut être redémarrée et ses paramètres (et non ceux de la base de données) peuvent être modifiés. |
Cas particuliers
Ne modifiez pas l'endpoint ou la zone de l'instance source ApsaraDB RDS for PostgreSQL pendant l'exécution d'une tâche de migration. Cela entraînerait l'échec de la tâche.
Configurer une tâche de migration
Étape 1 : Accéder à la page Data Migration
Utilisez la console DTS ou la console DMS.
Console DTS :
Connectez-vous à la console DTS.
Dans le volet de navigation de gauche, cliquez sur Data Migration.
Dans le coin supérieur gauche, sélectionnez la région où résidera l'instance de migration.
Console DMS :
Les étapes réelles peuvent varier selon le mode et la disposition de votre console DMS. Consultez Mode simple pour une référence de disposition, ou découvrez comment personnaliser la disposition de la console DMS .
Connectez-vous à la console DMS.
Dans la barre de navigation supérieure, placez le pointeur sur Data + AI > DTS (DTS) > Data Migration.
Dans la liste déroulante à droite de Data Migration Tasks, sélectionnez la région où résidera l'instance de migration.
Étape 2 : Créer une tâche
Cliquez sur Create Task pour ouvrir la page de configuration de la tâche.
Étape 3 : Configurer les bases de données source et de destination
Après avoir configuré les bases de données source et de destination, lisez les Limits affichées en haut de la page. Ignorer cette étape peut entraîner des échecs de tâche ou une incohérence des données.
Configurez les paramètres suivants pour les bases de données source et de destination.
| Section | Paramètre | Description |
|---|---|---|
| N/A | Task Name | Nom de la tâche DTS. DTS génère un nom automatiquement. Spécifiez un nom descriptif pour identifier facilement la tâche. Le nom n'a pas besoin d'être unique. |
| Source Database | Select Existing Connection | Si l'instance est déjà enregistrée auprès de DTS, sélectionnez-la dans la liste déroulante. DTS remplit automatiquement les autres paramètres. Sinon, configurez les paramètres ci-dessous. Dans la console DMS, sélectionnez l'instance dans la liste déroulante Select a DMS database instance. |
| Database Type | Sélectionnez PostgreSQL. | |
| Access Method | Sélectionnez Alibaba Cloud Instance. | |
| Instance Region | Région de l'instance source. | |
| Instance ID | ID de l'instance source. | |
| Database Name | Nom de la base de données contenant les objets à migrer. | |
| Database Account | Compte pour l'instance source. Consultez Autorisations requises. | |
| Database Password | Mot de passe du compte de base de données. | |
| Encryption | Sélectionnez Non-encrypted (par défaut) ou SSL-encrypted. Pour le chiffrement SSL, téléchargez le CA Certificate, et éventuellement le Client Certificate, la Private Key of Client Certificate et le Private Key Password of Client Certificate. Consultez Chiffrement SSL pour les instructions de configuration. | |
| Destination Database | Select Existing Connection | Identique à la source. |
| Database Type | Sélectionnez PostgreSQL. | |
| Access Method | Sélectionnez Alibaba Cloud Instance. | |
| Instance Region | Région de l'instance de destination. | |
| Instance ID | ID de l'instance de destination. | |
| Database Name | Nom de la base de données de destination. | |
| Database Account | Compte pour l'instance de destination. Consultez Autorisations requises. | |
| Database Password | Mot de passe du compte de base de données. | |
| Encryption | Mêmes options que pour la source. |
Étape 4 : Tester la connectivité
Cliquez sur Test Connectivity and Proceed en bas de la page.
Les blocs CIDR du serveur DTS doivent être ajoutés aux paramètres de sécurité des bases de données source et de destination. Pour les instructions, consultez Ajouter les blocs CIDR des serveurs DTS . Si la source ou la destination utilise une méthode d'accès autre que Alibaba Cloud Instance , cliquez sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers .
Étape 5 : Configurer les objets à migrer
Sur la page Configure Objects, configurez les paramètres de migration.
Types de migration :
| Objectif | Sélectionner |
|---|---|
| Migration complète (avec temps d'arrêt) | Schema Migration et Full Data Migration |
| Migration en ligne (temps d'arrêt minimal) | Schema Migration, Full Data Migration et Incremental Data Migration |
Si vous ne sélectionnez pas Incremental Data Migration , n'écrivez pas de données dans la source pendant la migration pour garantir la cohérence des données. La migration de schéma copie les clés étrangères vers la destination.
Mode de traitement des tables en conflit :
| Mode | Comportement |
|---|---|
| Precheck and Report Errors | Vérifie la présence de tables portant des noms identiques dans la source et la destination avant la migration. En cas de conflits, la pré-vérification échoue et la tâche ne démarre pas. Pour résoudre les conflits sans supprimer les tables de destination, utilisez le mappage de noms d'objets pour renommer les tables migrées. Consultez Mapper les noms d'objets. |
| Ignore Errors and Proceed | Ignore la vérification des conflits. Pendant la migration complète, les enregistrements en conflit ne sont pas migrés (les enregistrements de destination existants sont conservés). Pendant la migration incrémentielle, les enregistrements en conflit écrasent les enregistrements de destination existants. Utilisez ce mode avec prudence, car il peut exposer vos données à des risques d'incohérence. |
Objets source :
Sélectionnez un ou plusieurs schémas ou tables dans Source Objects et cliquez sur 
pour les ajouter à Selected Objects.
Si vous sélectionnez des tables (plutôt que des schémas), DTS ne migre pas d'autres objets tels que les vues, les déclencheurs et les procédures stockées. Si une table possède un type de données SERIAL et que la migration de schéma est sélectionnée, sélectionnez également Sequence ou migrez le schéma complet.
Objets sélectionnés :
Pour renommer un seul objet dans la destination, faites un clic droit dessus dans Selected Objects. Consultez Mapper le nom d'un seul objet.
Pour renommer plusieurs objets à la fois, cliquez sur Batch Edit. Consultez Mapper plusieurs noms d'objets à la fois.
Pour filtrer les lignes par condition, faites un clic droit sur une table et spécifiez une condition WHERE. Consultez Spécifier des conditions de filtre.
Pour sélectionner des opérations SQL spécifiques à migrer pour une table, faites un clic droit sur la table et choisissez les opérations. Consultez Opérations SQL prises en charge pour la migration incrémentielle.
Le renommage d'un objet avec le mappage de noms d'objets peut entraîner l'échec de la migration des objets dépendants.
Cliquez sur Next: Advanced Settings.
Paramètres avancés :
| Paramètre | Description |
|---|---|
| Dedicated Cluster for Task Scheduling | Par défaut, DTS utilise 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 après un échec de connexion. Plage : 10–1 440 minutes. Par défaut : 720. Définissez cette valeur sur au moins 30. Si DTS se reconnecte dans la fenêtre de nouvelle tentative, la tâche reprend ; sinon, elle échoue. Remarque
Si plusieurs tâches partagent la même source ou destination, la durée de nouvelle tentative définie le plus récemment s'applique à toutes. DTS continue de facturer pendant les nouvelles tentatives. |
| Retry Time for Other Issues | Durée pendant laquelle DTS effectue des tentatives après des échecs d'opérations DDL ou DML. Plage : 1–1 440 minutes. Par défaut : 10. Définissez cette valeur sur plus de 10. Cette valeur doit être inférieure à Retry Time for Failed Connections. |
| Enable Throttling for Full Data Migration | Limite le débit de migration pour réduire la charge sur la source et la destination. Configurez QPS to the source database, RPS of Full Data Migration et Data migration speed for full migration (MB/s). Disponible uniquement lorsque la migration complète des données est sélectionnée. |
| Enable Throttling for Incremental Data Migration | Limite le débit de la migration incrémentielle. Configurez RPS of Incremental Data Migration et Data migration speed for incremental migration (MB/s). Disponible uniquement lorsque la migration incrémentielle des données est sélectionnée. |
| Environment Tag | Tag facultatif pour identifier l'instance DTS par environnement. |
| Configure ETL | Activez l'extraction, la transformation et le chargement (ETL) pour traiter les données pendant la migration. Sélectionnez Yes pour saisir les instructions de traitement des données. Consultez Configurer ETL dans une tâche de migration ou de synchronisation de données. |
| Monitoring and Alerting | Configurez des alertes pour les échecs de tâche ou une latence de migration élevée. Sélectionnez Yes et configurez le seuil d'alerte et les paramètres de notification. Consultez Configurer la surveillance et les alertes lors de la création d'une tâche DTS. |
Cliquez sur Next Step: Data Verification pour configurer la vérification des données. Consultez Configurer une tâche de vérification des données.
Étape 6 : Exécuter la pré-vérification
Cliquez sur Next: Save Task Settings and Precheck.
Pour prévisualiser les paramètres API pour cette configuration de 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 démarrer la tâche. La tâche ne peut pas démarrer tant que la pré-vérification n'a pas réussi.
Si un élément de pré-vérification échoue, cliquez sur View Details pour voir la cause. Corrigez le problème et cliquez sur Precheck Again.
-
Si un élément déclenche une alerte :
Si l'alerte ne peut pas être ignorée, corrigez le problème et relancez la pré-vérification.
Si l'alerte peut être ignorée, cliquez sur Confirm Alert Details, puis cliquez sur Ignore > OK > Precheck Again. Ignorer une alerte peut provoquer une incohérence des données.
Étape 7 : Acheter une instance et démarrer la tâche
Attendez que le Success Rate atteigne 100 %, puis cliquez sur Next: Purchase Instance.
-
Sur la page Purchase Instance, configurez l'instance :
Section Paramètre Description New Instance Class 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. Sélectionnez en fonction de votre volume de données et de vos exigences de temps. Consultez Classes d'instances des instances de migration de données. Lisez et acceptez les Data Transmission Service (Pay-as-you-go) Service Terms en cochant la case.
Cliquez sur Buy and Start, puis cliquez sur OK dans la boîte de dialogue de confirmation.
La tâche apparaît sur la page Data Migration.
Si la tâche n'inclut pas de migration incrémentielle, elle s'arrête automatiquement une fois terminée. Le statut affiche Completed.
Si la tâche inclut une migration incrémentielle, elle s'exécute en continu. Le statut affiche Running.
Basculement vers la base de données de destination
Pour les migrations en ligne utilisant la migration incrémentielle des données, suivez ces étapes pour effectuer le basculement avec une perte de données minimale.
Surveillez la latence de migration. Sur la page Data Migration, vérifiez la latence de la tâche de migration incrémentielle. Attendez que la latence tombe à 0 ou près de 0, ce qui signifie que la destination est presque entièrement synchronisée avec la source.
Arrêtez les écritures sur la source. Une fois la latence proche de 0, empêchez votre application d'écrire dans la base de données source.
Confirmez que la latence atteint 0. Après avoir arrêté les écritures, confirmez que la latence de la migration incrémentielle atteint 0. Cela garantit que toutes les modifications ont été répliquées vers la destination.
Mettez à jour les séquences dans la destination. Les nouvelles séquences dans la destination n'incrémentent pas à partir de la valeur maximale des séquences de la source. Avant de basculer le trafic, mettez à jour les valeurs de départ de toutes les séquences dans la destination pour éviter les conflits d'ID.
Vérifiez les données. Si vous avez configuré la vérification des données, consultez les résultats de vérification pour confirmer la cohérence des données entre la source et la destination.
Basculez votre application. Mettez à jour la chaîne de connexion de votre application pour qu'elle pointe vers l'instance de destination.
Libérez la tâche DTS. Après avoir confirmé que l'application fonctionne correctement sur la destination, arrêtez et libérez la tâche de migration DTS. DTS supprime automatiquement les tables temporaires et l'emplacement de réplication de la source après la libération de la tâche.
DTS retente une tâche ayant échoué pendant jusqu'à 7 jours. Avant de basculer les charges de travail vers la destination, arrêtez ou libérez toutes les tâches ayant échoué, ou exécutez REVOKE pour supprimer les autorisations d'écriture du compte DTS sur la base de données de destination. Sinon, une tâche ayant échoué et reprise pourrait écraser les données de la destination.
Étapes suivantes
Logical Replication Slot Failover — activez cette fonctionnalité avant d'effectuer un basculement primaire/secondaire sur l'instance source.
Mapper les noms d'objets — renommez les objets dans la destination pendant la migration.
Configurer une tâche de vérification des données — vérifiez la cohérence des données après la migration.
Classes d'instances des instances de migration de données — choisissez la classe d'instance appropriée pour vos exigences de vitesse de migration.