Utilisez Data Transmission Service (DTS) pour synchroniser les données d'une instance ApsaraDB RDS for MySQL vers un cluster ApsaraDB for ClickHouse. DTS gère l'initialisation complète des données et la synchronisation incrémentielle continue via Change Data Capture (CDC), ce qui permet à votre cluster ClickHouse de rester à jour sans intervention manuelle.
Prérequis
Avant de commencer, assurez-vous d'avoir :
Autorisé DTS à accéder aux ressources Alibaba Cloud. Pour plus d'informations, consultez la rubrique Autoriser DTS à accéder aux ressources Alibaba Cloud.
Créé un cluster ApsaraDB for ClickHouse exécutant la version V20.8 ou ultérieure, avec un espace de stockage disponible supérieur à la taille totale des données de l'instance RDS MySQL source. Pour plus d'informations, consultez la rubrique Créer un cluster ApsaraDB for ClickHouse.
Créé une base de données de destination dans le cluster ApsaraDB for ClickHouse. Pour plus d'informations, consultez la rubrique Créer une base de données.
Attribuez à la base de données de destination le même nom que celui de la base de données source dans RDS MySQL. Si les noms diffèrent, utilisez la fonctionnalité de mappage de noms dans la section Selected Objects lors de l'étape Configure Objects and Advanced Settings pour mapper le nom de la base de données source au nom de la base de données de destination. Pour plus d'informations, consultez la rubrique Mapper les noms d'objets.
Facturation
| Type de synchronisation | Tarification |
|---|---|
| Synchronisation du schéma et synchronisation complète des données | Gratuit |
| Synchronisation incrémentielle des données | Payant. Pour plus d'informations, consultez la rubrique Présentation de la facturation. |
Opérations SQL prises en charge
| Type d'opération | Instructions SQL |
|---|---|
| DML | INSERT, UPDATE, DELETE |
| DDL | CREATE TABLE, DROP TABLE, TRUNCATE TABLE, ADD COLUMN, MODIFY COLUMN, DROP COLUMN |
Comportement de la synchronisation DDL
Comprendre le comportement de chaque instruction DDL pendant la synchronisation vous aide à éviter toute perte de données inattendue ou tout échec de tâche.
| Opération DDL | Comportement |
|---|---|
| CREATE TABLE | Propagée automatiquement. La table de destination est créée avec les champs ajoutés par DTS (_sign, _version, _is_deleted). |
| DROP TABLE | Propagée automatiquement. La table de destination est supprimée. |
| TRUNCATE TABLE | Propagée automatiquement. Toutes les lignes de la table de destination sont supprimées. |
| ADD COLUMN | Propagée automatiquement. Les nouvelles lignes répliquées après la modification incluent la colonne ajoutée. |
| MODIFY COLUMN | Propagée automatiquement. |
| DROP COLUMN | Propagée automatiquement. |
| RENAME TABLE | Non pris en charge. La tâche peut échouer si la source exécute RENAME TABLE. |
| INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER, FK | Pris en charge. |
Mappages de types de données
MySQL et ApsaraDB for ClickHouse prennent en charge différents types de données, de sorte qu'un mappage un-à-un n'est pas toujours possible. DTS mappe les types MySQL aux types équivalents les plus proches pris en charge par ApsaraDB for ClickHouse lors de la synchronisation initiale du schéma. Pour plus d'informations, consultez la rubrique Mappages de types de données pour la synchronisation initiale du schéma.
Autorisations des comptes de base de données
| Base de données | Autorisations requises | Comment configurer |
|---|---|---|
| RDS MySQL source | Autorisations de lecture sur tous les objets à synchroniser | Créer un compte et Modifier les autorisations d'un compte |
| Cluster ApsaraDB for ClickHouse de destination (v22.8 ou ultérieure) | Autorisations de lecture et d'écriture sur la base de données de destination. Un compte privilégié répond aux exigences. | Gestion des comptes Community-compatible Edition |
| Cluster ApsaraDB for ClickHouse de destination (v21.8) | Read/Write And Settings et Allow DDL | Gestion des comptes Community-compatible Edition |
Si le compte de la base de données source n'a pas été créé via la console RDS MySQL, assurez-vous que le compte dispose des autorisations REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW et SELECT.
Limites
Limites de la base de données source
| Limite | Détails |
|---|---|
| Clé primaire requise | Les tables sans clé primaire ne peuvent pas être synchronisées. |
| Limite de synchronisation au niveau de la table | Lors de la synchronisation au niveau de la table avec des modifications d'objets (telles que le mappage de noms), une seule tâche prend en charge un maximum de 1 000 tables. Si vous dépassez cette limite, répartissez les tables sur plusieurs tâches ou configurez la tâche pour synchroniser la base de données entière. |
| Conservation des journaux binaires | Conservez les journaux binaires locaux pendant au moins 3 jours (7 jours recommandés) pour RDS MySQL, et au moins 7 jours pour MySQL autogéré. Si DTS ne peut pas récupérer les journaux binaires requis, la tâche échoue. Dans les cas extrêmes, cela peut entraîner une incohérence ou une perte de données. Les problèmes causés par des périodes de conservation insuffisantes ne sont pas couverts par le SLA DTS. Pour configurer la période de conservation d'une instance RDS MySQL, consultez la rubrique Supprimer automatiquement les journaux locaux. |
| Aucune opération DDL pendant la synchronisation | N'exécutez pas d'opérations DDL modifiant les schémas de base de données ou de tables pendant la synchronisation du schéma ou la synchronisation complète, car la tâche échouerait. Pendant la synchronisation complète, DTS interroge la base de données source, ce qui crée des verrous de métadonnées susceptibles de bloquer les opérations DDL. |
| Données hors journal binaire | Les données générées par des opérations qui n'écrivent pas dans les journaux binaires, telles que les restaurations de sauvegarde physique ou les opérations en cascade, ne sont pas synchronisées. Si cela se produit, supprimez les objets concernés de la tâche de synchronisation et ajoutez-les à nouveau, si votre activité métier le permet. Pour plus d'informations, consultez la rubrique Modifier les objets à synchroniser. |
| Colonnes invisibles (MySQL 8.0.23+) | DTS peut ne pas lire les colonnes cachées invisibles dans MySQL 8.0.23 ou versions ultérieures, ce qui peut entraîner une perte de données. Exécutez ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; pour rendre les colonnes cachées visibles avant la synchronisation. Pour plus d'informations, consultez la rubrique Colonnes invisibles. |
Configuration des journaux binaires
Configurez ces paramètres avant de démarrer la tâche de synchronisation :
Pour ApsaraDB RDS for MySQL :
ApsaraDB RDS for MySQL active la journalisation binaire par défaut. Vérifiez les points suivants :
Définissez
binlog_row_imagesurfull. Si ce n'est pas le cas, la pré-vérification échoue et la tâche ne peut pas démarrer. Pour obtenir des instructions, consultez la rubrique Configurer les paramètres de l'instance.Conservez les journaux binaires locaux pendant au moins 3 jours (7 jours recommandés).
Pour MySQL autogéré :
Activez la journalisation binaire.
Définissez
binlog_formatsurrow.Définissez
binlog_row_imagesurfull.Pour les clusters à double primaire, activez également
log_slave_updatesafin que DTS puisse capturer tous les événements de journal binaire.Conservez les journaux binaires locaux pendant au moins 7 jours.
Pour obtenir des instructions, consultez la rubrique Créer un compte et configurer la journalisation binaire pour une base de données MySQL autogérée.
Autres limites
| Limite | Détails |
|---|---|
| Syntaxe DDL non standard | Si les instructions DDL de l'instance RDS MySQL source ne suivent pas la syntaxe MySQL standard, la tâche peut échouer ou des données peuvent être perdues. |
| DDL en ligne en mode table temporaire | Si la base de données source utilise le DDL en ligne en mode table temporaire, y compris les scénarios de fusion multi-tables ou les index basés sur des fonctions sur des colonnes de clé unique, une perte de données ou un échec de la tâche peut se produire. |
| Outils DDL en ligne | DMS et gh-ost : DTS synchronise uniquement les instructions DDL d'origine, ce qui peut entraîner un verrouillage temporaire des tables de destination. pt-online-schema-change n'est pas pris en charge lors de la synchronisation au niveau de la table ; s'il est utilisé à la source, des données peuvent être perdues ou la tâche peut échouer. Vous pouvez utiliser Data Management (DMS) pour effectuer des opérations DDL en ligne à la place. Pour plus d'informations, consultez la rubrique Modifier les schémas sans verrouiller les tables. |
| Conflits de clés primaires ou uniques | Pendant la synchronisation complète, DTS conserve l'enregistrement de destination et ignore l'enregistrement source conflictuel. Pendant la synchronisation incrémentielle, DTS écrase l'enregistrement de destination avec l'enregistrement source. Si les schémas de table sont incohérents, l'initialisation des données peut échouer, entraînant un échec partiel ou total de la synchronisation. |
| Plage de données de type heure | ApsaraDB for ClickHouse applique des limites de plage aux données de type heure. Si les données horaires dans RDS MySQL se situent en dehors de ces plages, les valeurs synchronisées seront incorrectes. Consultez la section Informations sur l'heure. |
| Clé de partition | La clé de partition ne peut pas être un champ nullable. Types pris en charge : BIGINT, INT, TIMESTAMP, DATETIME et DATE. |
| Limite de base de données | Le nombre de bases de données à synchroniser ne peut pas dépasser 256, qui est la limite d'ApsaraDB for ClickHouse. |
| Conventions de nommage | Les noms de bases de données, de tables et de colonnes doivent respecter les conventions de nommage d'ApsaraDB for ClickHouse. Pour plus d'informations, consultez la rubrique Conventions de nommage des objets. |
| Champs ajoutés par DTS | DTS ajoute les champs _sign, _is_deleted et _version aux tables de destination lors de la synchronisation du schéma. Si vous ne sélectionnez pas Schema Synchronization, créez manuellement les tables de destination et ajoutez ces champs. Consultez la section Informations sur les tables et les champs. |
| Impact sur les performances | La synchronisation complète des données consomme des ressources de lecture et d'écriture des bases de données source et de destination. Exécutez la synchronisation pendant les heures creuses pour minimiser l'impact. |
| Écritures externes vers la destination | N'autorisez aucune source de données autre que DTS à écrire dans la base de données de destination pendant la synchronisation. Cela entraînerait une incohérence des données. |
| Always-Encrypted | La synchronisation complète des données n'est pas prise en charge pour les instances RDS MySQL avec Always-Encrypted activé. Les instances avec Transparent Data Encryption (TDE) activé prennent en charge tous les types de synchronisation. |
| Récupération après échec de tâche | En cas d'échec d'une tâche, l'équipe support DTS tentera de la restaurer dans un délai de 8 heures. Elle peut redémarrer la tâche ou ajuster les paramètres de la tâche DTS (et non les paramètres de la base de données) lors de la restauration. |
Notes d'utilisation
Pour les sources MySQL autogérées :
Si un basculement primaire/secondaire se produit pendant la synchronisation, la tâche échoue.
DTS calcule la latence en comparant l'horodatage du dernier enregistrement synchronisé avec l'heure actuelle. Si aucune opération DML n'est exécutée pendant une période prolongée, le rapport de latence peut devenir imprécis. Exécutez une opération DML dans la base de données source pour réinitialiser la latence signalée. Si vous sélectionnez une base de données entière pour la synchronisation, créez une table de heartbeat et mettez-la à jour chaque seconde.
DTS exécute périodiquement
CREATE DATABASE IF NOT EXISTS \test\`` dans la base de données source pour faire avancer le décalage du journal binaire.Si la source est Amazon Aurora MySQL ou une autre instance MySQL en cluster, assurez-vous que le nom de domaine ou l'adresse IP utilisé dans la configuration de la tâche résout toujours vers un nœud en lecture/écriture (RW).
Pour les sources ApsaraDB RDS for MySQL :
Les instances en lecture seule, telles que les instances en lecture seule ApsaraDB RDS for MySQL 5.6, qui n'enregistrent pas les journaux de transactions, ne peuvent pas servir de bases de données sources.
DTS exécute périodiquement
CREATE DATABASE IF NOT EXISTS \test\`` dans la base de données source pour faire avancer le décalage du journal binaire.
Créer une tâche de synchronisation
La configuration de la tâche comporte sept étapes. Une fois la tâche lancée, DTS effectue d'abord une copie complète des données source, puis applique continuellement les modifications incrémentielles.
Étape 1 : Accéder à la page de synchronisation des données
Ouvrez la liste des tâches Data Synchronization dans la région de destination en utilisant l'une des méthodes suivantes :
Console DTS
Connectez-vous à la console DTS.
Dans le volet de navigation de gauche, cliquez sur Data Synchronization.
Dans le coin supérieur gauche, sélectionnez la région où sera située l'instance de synchronisation.
Console DMS
Les étapes peuvent varier selon le mode et la disposition de la console DMS. Pour plus d'informations, consultez Simple mode console et Customize the layout and style of the DMS console .
Connectez-vous à la console DMS.
Dans la barre de menu supérieure, choisissez Data + AI > DTS (DTS) > Data Synchronization.
À droite de Data Synchronization Tasks, sélectionnez la région de l'instance de synchronisation.
É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
| Catégorie | Paramètre | Description |
|---|---|---|
| Aucun | Nom de la tâche | DTS génère automatiquement un nom. Spécifiez un nom descriptif pour faciliter l'identification. Le nom n'a pas besoin d'être unique. |
| Base de données source | Sélectionner une connexion existante | Sélectionnez une instance de base de données enregistrée dans la liste déroulante pour remplir automatiquement les détails de la connexion. Dans la console DMS, ce paramètre est intitulé Select a DMS database instance. Si aucune instance enregistrée n'est disponible, configurez la connexion manuellement. |
| Type de base de données | Sélectionnez MySQL. | |
| Méthode d'accès | Sélectionnez Alibaba Cloud Instance. | |
| Région de l'instance | Sélectionnez la région où réside l'instance RDS MySQL source. | |
| Répliquer les données entre les comptes Alibaba Cloud | Sélectionnez No (même compte Alibaba Cloud). | |
| ID de l'instance RDS | Sélectionnez l'ID de l'instance RDS MySQL source. | |
| Compte de base de données | Saisissez le compte de base de données. Pour les exigences en matière d'autorisations, consultez Autorisations du compte de base de données. | |
| Mot de passe de la base de données | Saisissez le mot de passe du compte de base de données. | |
| Chiffrement | Sélectionnez Non-encrypted ou Chiffré SSL. Si vous sélectionnez SSL-encrypted, activez d'abord le chiffrement SSL sur l'instance RDS MySQL. Pour plus d'informations, consultez Utiliser un certificat cloud pour activer rapidement le chiffrement SSL. | |
| Base de données de destination | Sélectionner une connexion existante | Sélectionnez une instance de base de données enregistrée dans la liste déroulante. Dans la console DMS, ce paramètre est intitulé Select a DMS database instance. Si aucune instance enregistrée n'est disponible, configurez la connexion manuellement. |
| Type de base de données | Sélectionnez ClickHouse. | |
| Méthode d'accès | Sélectionnez Alibaba Cloud Instance. | |
| Région de l'instance | Sélectionnez la région où réside le cluster ApsaraDB for ClickHouse de destination. | |
| Répliquer les données entre les comptes Alibaba Cloud | Sélectionnez No (même compte Alibaba Cloud). | |
| Type de cluster | Sélectionnez le type du cluster ApsaraDB for ClickHouse. | |
| ID du cluster | Sélectionnez l'ID du cluster ApsaraDB for ClickHouse de destination. | |
| Compte de base de données | Saisissez le compte de base de données. Pour les exigences en matière d'autorisations, consultez Autorisations du compte de base de données. | |
| Mot de passe de la base de données | Saisissez le mot de passe du compte de base de données. |
Étape 4 : Tester la connectivité
Cliquez sur Test Connectivity and Proceed en bas de la page.
Ajoutez les blocs CIDR des serveurs DTS aux paramètres de sécurité des bases de données source et de destination pour autoriser l'accès. Cette opération peut être effectuée automatiquement ou manuellement. Pour plus d'informations, consultez Ajouter la liste d'autorisation IP des serveurs DTS .
Si la source ou la destination est une base de données gérée par l'utilisateur (c'est-à-dire que Méthode d'accès n'est pas Alibaba Cloud Instance ), cliquez également sur Test Connectivity dans la boîte de dialogue CIDR Blocks of DTS Servers .
Étape 5 : Configurer les objets et les paramètres avancés
Configurer les objets
Sur la page Configure Objects , spécifiez l'étendue de la synchronisation.
| Paramètre | Description |
|---|---|
| Synchronization Types | DTS sélectionne toujours Synchronisation des données incrémentielles. Par défaut, Synchronisation du schéma et Synchronisation complète des données sont également sélectionnés. Après la pré-vérification, DTS initialise le cluster de destination avec une copie complète des données source, qui sert de référence pour la synchronisation incrémentielle. |
| Processing Mode of Conflicting Tables | Pré-vérifier et signaler les erreurs : Vérifie la présence de tables portant des noms identiques dans la base de données de destination. Si des conflits sont détectés, une erreur est signalée lors de la pré-vérification et la tâche ne démarre pas. Si vous ne pouvez pas supprimer ou renommer la table en conflit, utilisez le mappage de noms pour attribuer un nom différent dans la destination. Pour plus d'informations, consultez Mappage des noms de colonnes de tables de base de données. Ignorer les erreurs et continuer : Ignore la vérification des noms de tables en double. Lors de la synchronisation complète, DTS conserve l'enregistrement de destination et ignore les enregistrements source en conflit. Lors de la synchronisation incrémentielle, DTS écrase les enregistrements de destination. Si les schémas de table sont incohérents, l'initialisation des données peut échouer. Utilisez cette option avec prudence. |
| Capitalization of Object Names in Destination Instance | Définit la politique de sensibilité à la casse pour les noms de bases de données, de tables et de colonnes dans la destination. La valeur par défaut est Politique par défaut de DTS. Pour plus d'informations, consultez Politique de casse pour les noms d'objets de destination. |
| Source Objects | Cliquez sur les objets à synchroniser dans la zone Objets source, puis cliquez sur la flèche pour les déplacer vers la zone Objets sélectionnés. Sélectionnez les objets au niveau de la base de données ou de la table. |
| Selected Objects | Pour renommer un seul objet dans la destination, faites un clic droit dessus dans la zone Selected Objects . Pour renommer plusieurs objets en masse, cliquez sur Batch Edit dans le coin supérieur droit. Pour filtrer les données, faites un clic droit sur une table dans la zone Objets sélectionnés et définissez les conditions de filtre. Pour plus d'informations, consultez Définir les conditions de filtre. Notez que l'utilisation du mappage de noms peut entraîner l'échec de la synchronisation des objets dépendants. |
Cliquez sur Next: Advanced Settings .
Paramètres avancés
| Paramètre | Description |
|---|---|
| Dedicated Cluster for Task Scheduling | DTS utilise un cluster partagé par défaut. Pour une meilleure stabilité des tâches, achetez un cluster dédié. Pour plus d'informations, consultez Qu'est-ce qu'un cluster dédié DTS ?. |
| Time zone of destination database | Sélectionnez le fuseau horaire pour les données DateTime écrites dans le cluster ApsaraDB for ClickHouse. |
| Retry Time for Failed Connections | Définit la durée pendant laquelle DTS effectue des nouvelles tentatives après un échec de connexion. Valeur par défaut : 720 minutes. Plage : 10–1 440 minutes. Définissez une valeur supérieure ou égale à 30 minutes. Si la connexion est rétablie dans ce délai, la tâche reprend automatiquement. Si plusieurs instances DTS partagent une source ou une destination, DTS utilise la durée de nouvelle tentative la plus courte configurée parmi toutes les instances. DTS facture le temps d'exécution de la tâche pendant les nouvelles tentatives ; libérez l'instance DTS rapidement après avoir libéré les instances source ou de destination. |
| Retry Time for Other Issues | Définit la durée pendant laquelle DTS effectue des nouvelles tentatives après des erreurs autres que les échecs de connexion (telles que les échecs d'exécution DDL ou DML). Valeur par défaut : 10 minutes. Plage : 1–1 440 minutes. Doit être inférieure à Durée de nouvelle tentative en cas d'échec de connexion. |
| Enable Throttling for Full Data Synchronization | Limite le taux de synchronisation complète pour réduire la charge sur la base de données de destination. Définissez Queries per second (QPS) to the source database , RPS de la migration complète des données et Vitesse de migration des données pour la migration complète (Mo/s). Disponible uniquement lorsque Synchronisation complète des données est sélectionné. Vous pouvez également ajuster le débit après le démarrage de la tâche. |
| Enable Throttling for Incremental Data Synchronization | Limite le taux de synchronisation incrémentielle. Définissez RPS of Incremental Data Synchronization et Vitesse de synchronisation des données pour la synchronisation incrémentielle (Mo/s). |
| Whether to delete SQL operations on heartbeat tables of forward and reverse tasks | Contrôle si DTS écrit du SQL de heartbeat dans la base de données source. Oui : N'écrit pas de SQL de heartbeat — l'instance DTS peut afficher une latence plus élevée. Non : Écrit du SQL de heartbeat — cela peut interférer avec les sauvegardes physiques et le clonage sur la source. |
| Environment Tag | Taguez éventuellement l'instance pour identifier son environnement. |
| Configure ETL | Oui : Active l'extraction, la transformation et le chargement (ETL). Saisissez les instructions de traitement des données dans l'éditeur de code. Pour plus d'informations, consultez Configurer ETL dans une tâche de migration ou de synchronisation de données. Non : Désactive ETL. |
| Monitoring and Alerting | Oui : Configure les alertes. Définissez le seuil d'alerte et les contacts de notification. Pour plus d'informations, consultez Configurer la surveillance et les alertes lors de la configuration de la tâche. Non : Aucune alerte configurée. |
Configurer les champs de base de données et de table
Cliquez sur Next: Configure Database and Table Fields pour configurer le Type , la Primary Key Column , la Clé de tri, la Clé de distribution et la Clé de partition pour chaque table synchronisée vers ClickHouse.
DTS fournit une configuration par défaut. Définissez Definition Status sur Tous pour examiner et modifier toutes les tables.
La Colonne de clé primaire et la Clé de tri prennent en charge les clés composites — sélectionnez plusieurs champs dans la liste déroulante.
Un seul champ peut être sélectionné comme Clé de distribution.
Sélectionnez une ou plusieurs colonnes de la Colonne de clé primaire comme Clé de partition.
La Clé de partition est facultative, mais si elle est spécifiée, elle ne peut pas être un champ nullable. Types pris en charge : BIGINT, INT, TIMESTAMP, DATETIME et DATE. Pour la logique de calcul, consultez Logique de calcul de la clé de partition.
Pour plus d'informations sur les colonnes de clé primaire, les clés de tri et les clés de partition, consultez CREATE TABLE.
Étape 6 : Enregistrer la tâche et exécuter la pré-vérification
Pour prévisualiser les paramètres API de cette tâche, survolez Suivant : Enregistrer les paramètres de la tâche et pré-vérifier et cliquez sur Preview OpenAPI parameters dans l'infobulle.
Cliquez sur Next: Save Task Settings and Precheck .
DTS exécute une pré-vérification avant le démarrage de la tâche. La tâche ne démarre que si la pré-vérification réussit.
Si la pré-vérification échoue, cliquez sur View Details à côté de l'élément ayant échoué, corrigez le problème et relancez la pré-vérification.
-
Si la pré-vérification génère des avertissements :
Pour les avertissements non ignorables, cliquez sur View Details , corrigez le problème et relancez la pré-vérification.
Pour les avertissements ignorables, cliquez sur Confirm Alert Details > Ignore > OK , puis cliquez sur Precheck Again . Ignorer les avertissements peut entraîner des incohérences de données. Procédez avec prudence.
Étape 7 : Acheter l'instance de synchronisation
Lorsque le Taux de réussite atteint 100 %, cliquez sur Next: Purchase Instance .
Sur la page Purchase , sélectionnez la méthode de facturation et la classe d'instance.
| Catégorie | Paramètre | Description |
|---|---|---|
| Nouvelle classe d'instance | Méthode de facturation | Abonnement : Payez à l'avance pour une durée fixe. Convient aux tâches continues à long terme. Options mensuelles : 1 à 9 mois. Options annuelles : 1, 2, 3 ou 5 ans. Paiement à l'utilisation : Facturé à l'heure en fonction de l'utilisation réelle. Convient aux tâches à court terme ou de test. |
| Paramètres du groupe de ressources | — | Le groupe de ressources pour l'instance. Par défaut : default resource group . Pour plus d'informations, consultez Qu'est-ce que Resource Management ?. |
| Classe d'instance | — | Affecte les performances de synchronisation. Sélectionnez en fonction de vos besoins métier. Pour plus d'informations, consultez Spécifications des canaux de synchronisation de données. |
Lisez et cochez la case Data Transmission Service (Pay-as-you-go) Service Terms .
Cliquez sur Buy and Start , puis cliquez sur OK .
Surveillez la progression de la tâche sur la page de synchronisation des données.
Annexe
Informations temporelles
| Type de données | Valeur minimale | Valeur maximale |
|---|---|---|
| Date | 1970-01-01 00:00:00 | 2149-06-06 00:00:00 |
| Date32 | 1925-01-01 00:00:00 | 2283-11-11 00:00:00 |
| DateTime | 1970-01-01 08:00:00 | 2106-02-07 14:28:15 |
| DateTime64 | 1925-01-01 08:00:00 | 2283-11-12 07:59:59 |
Informations sur les tables et les champs
Exigences relatives aux tables
Si vous n'utilisez pas la fonctionnalité de mappage de noms d'objets, les tables que vous créez doivent répondre aux exigences suivantes.
Si la table de destination spécifie un ENGINE, il doit s'agir de ENGINE = ReplicatedReplacingMergeTree(_version, _is_deleted) . Sinon, des incohérences de données peuvent se produire.
Instance Community Edition : Créez une table locale et une table distribuée. Le nom de la table distribuée doit correspondre au nom de la table source. Le nom de la table locale doit suivre le format
<nom_table_distribuée>_local.Instance Enterprise Edition : Créez une table portant le même nom que la table source.
Champs ajoutés par DTS
DTS ajoute les champs suivants aux tables de destination lors de la synchronisation du schéma. Pour interroger les données et filtrer les enregistrements supprimés, exécutez :
SELECT * FROM table_name FINAL WHERE _sign > 0;Le mot-clé FINAL filtre les lignes avec des clés de tri en double, et _sign > 0 exclut les enregistrements supprimés.
| Version | Champ | Type de données | Valeur par défaut | Description |
|---|---|---|---|---|
| Community Edition antérieure à v23.8 | _sign |
Int8 | 1 | Type d'opération DML. INSERT et UPDATE = 1. DELETE = -1. |
_version |
UInt64 | 1 | Horodatage de l'écriture de l'enregistrement dans ClickHouse. | |
| Enterprise Edition et Community Edition v23.8 ou ultérieure | _sign |
Int8 | 1 | Type d'opération DML. INSERT et UPDATE = 1. DELETE = -1. |
_is_deleted |
UInt8 | 0 | Indique si l'enregistrement est supprimé. INSERT et UPDATE = 0. DELETE = 1. |
|
_version |
UInt64 | 1 | Horodatage de l'écriture de l'enregistrement dans ClickHouse. |
Logique de calcul de la clé de partition
| Type de champ source | Logique de calcul |
|---|---|
| BIGINT | intDiv(field, 18014398509481984) |
| INT | intDiv(field, 4194304) |
| TIMESTAMP | toYYYYMM(field) |
| DATETIME | toYYYYMM(field) |
| DATE | toYYYYMM(field) |