Politiques de planification de l'intégration des données - Data Transmission Service

Data Transmission Service (DTS) propose la fonctionnalité d'intégration des données. Configurez une politique de planification pour migrer régulièrement les schémas et les données historiques de la base de données source vers la base de données de destination. Cette fonctionnalité offre une grande flexibilité pour la création d'entrepôts de données, par exemple pour mettre en place un entrepôt T+1. Cette rubrique décrit les politiques de planification de l'intégration des données, leurs limites et leurs scénarios d'utilisation.

Bases de données prises en charge

Toutes les bases de données compatibles avec la migration complète des données prennent en charge l'intégration des données. Pour plus d'informations, consultez la rubrique Scénarios de migration.

Facturation

Type de migration	Frais de configuration de la tâche	Frais de trafic Internet
Migration du schéma et migration complète des données	Gratuit.	Facturé uniquement lors d'une migration de données depuis Alibaba Cloud via Internet. Pour plus d'informations, consultez la rubrique Présentation de la facturation.

Méthode de configuration

Configurez la politique de planification d'une tâche d'intégration des données à l'étape Configure Migration Types and Objects.

Remarque

Pour savoir comment configurer une politique de planification, consultez la rubrique

Configurer une tâche d'intégration des données entre des instances RDS for MySQL

Politiques de planification

Politique de planification	Description	Scénario
Multi-replica mode	Selon le cycle de planification, DTS migre les schémas et les données historiques des objets sélectionnés de la base de données source vers la base de données de destination. Remarque Lors de l'exécution planifiée, DTS crée une base de données dans l'instance de destination pour recevoir les données migrées. Le nom de cette base de données est suffixé par `_yyyymmdd_HH_mm_ss`, correspondant à l'heure planifiée. Par exemple, si une tâche migre les données d'une base nommée dtstestdata et est planifiée le 10 février 2020 à 11:00:00, DTS crée une base de données nommée `dtstestdata_20200210_11_00_00` dans l'instance de destination. La base de données de destination doit disposer d'un espace suffisant pour stocker les données migrées à chaque cycle.	Cette politique convient aux tests nécessitant plusieurs réplicas de données historiques.
Resynchronization mode	Lors de la première exécution planifiée, DTS migre les schémas et les données historiques des objets sélectionnés vers la base de données de destination. À chaque exécution suivante, DTS migre à nouveau ces éléments. Avertissement Avant chaque nouvelle exécution, supprimez manuellement les schémas et les données migrés lors de l'exécution précédente. Sinon, la migration échouera. Si DTS ne prend pas en charge la migration du schéma pour une base de données spécifique, créez manuellement le schéma dans la base de données de destination en vous basant sur celui des objets requis.	Utilisez cette politique lorsque seule la dernière version des données historiques doit être conservée dans la base de données de destination, par exemple pour des tests ou une analyse.
Timestamp-based incremental data mode	DTS migre les données incrémentielles générées après la planification précédente vers la base de données de destination en se basant sur l'horodatage spécifié. Cette politique présente les limites suivantes : Cette politique est prise en charge uniquement si les bases de données source et de destination sont toutes deux des bases MySQL. Chaque table source doit contenir un champ d'horodatage. Spécifiez ce champ pour chaque table lors de la configuration de la tâche. Les tables sources ne doivent pas comporter de contraintes FOREIGN KEY, sous peine d'échec de la migration. Si vous mettez à jour une table enfant avec des contraintes FOREIGN KEY dans la base de destination, puis la table parent, une erreur survient lors de l'insertion dans la table enfant. Les enregistrements supprimés via les commandes DELETE ou TRUNCATE ne sont pas migrés. Remarque Si une table n'a pas de clé primaire, DTS utilise l'intégralité de l'enregistrement comme clé. La correspondance n'est établie que si tous les champs correspondent. DTS supprime alors les enregistrements correspondants et insère les nouveaux. En cas de conflit de clés primaires lors de l'écriture dans la base de destination, DTS exécute la commande REPLACE INTO pour insérer l'enregistrement.	Recommandée pour les migrations légères ne nécessitant pas le transfert de l'historique complet à chaque fois, par exemple pour la création d'un entrepôt T+1.