tencent cloud

Data Transfer Service

Release Notes and Announcements
Release Notes
Announcements
Product Introduction
Overview
Data Migration
Data Sync
Data Subscription (Kafka Edition)
Strengths
Supported Regions
Specification Description
Purchase Guide
Billing Overview
Configuration Change Description
Payment Overdue
Refund
Getting Started
Data Migration Guide
Data Sync Guide
Data Subscription Guide (Kafka Edition)
Preparations
Business Evaluation
Network Preparation
Adding DTS IP Addresses to the Allowlist of the Corresponding Databases
DTS Service Permission Preparation
Database and Permission Preparation
Configuring Binlog in Self-Built MySQL
Data Migration
Databases Supported by Data Migration
Cross-Account TencentDB Instance Migration
Migration to MySQL Series
Migrating to PostgreSQL
Migrating to MongoDB
Migrating to SQL Server
Migrating to Tencent Cloud Distributed Cache
Task Management
Data Sync
Databases Supported by Data Sync
Cross-Account TencentDB Instance Sync
Sync to MySQL series
Synchronize to PostgreSQL
Synchronization to MongoDB
Synchronize to Kafka
Task Management
Data Subscription (Kafka Edition)
Databases Supported by Data Subscription
MySQL series Data Subscription
Data Subscription for TDSQL PostgreSQL
MongoDB Data Subscription
Task Management
Consumption Management
Fix for Verification Failure
Check Item Overview
Cutover Description
Monitoring and Alarms
Supported Monitoring Indicators
Supported Events
Configuring Metric Alarms and Event Alarms via the Console
Configuring Indicator Monitoring and Event Alarm by APIs
Ops Management
Configuring Maintenance Time
Task Status Change Description
Practical Tutorial
Synchronizing Local Database to the Cloud
Creating Two-Way Sync Data Structure
Creating Many-to-One Sync Data Structure
Creating Multi-Site Active-Active IDC Architecture
Selecting Data Sync Conflict Resolution Policy
Using CLB as Proxy for Cross-Account Database Migration
Migrating Self-Built Databases to Tencent Cloud Databases via CCN
Best Practices for DTS Performance Tuning
FAQs
Data Migration
Data Sync
FAQs for Data Subscription Kafka Edition
Regular Expressions for Subscription
Error Handling
Common Errors
Failed Connectivity Test
Failed or Alarmed Check Item
Inability to Select Subnet During CCN Access
Slow or Stuck Migration
Data Sync Delay
High Data Subscription Delay
Data Consumption Exception
API Documentation
History
Introduction
API Category
Making API Requests
(NewDTS) Data Migration APIs
Data Sync APIs
Data Consistency Check APIs
(NewDTS) Data Subscription APIs
Data Types
Error Codes
DTS API 2018-03-30
Service Agreement
Service Level Agreements

Use Instructions

PDF
フォーカスモード
フォントサイズ
最終更新日: 2026-01-14 15:13:38

Impact on the Source Database

When Data Transfer Service (DTS) is used to perform a full data synchronization task, it occupies certain resources of the source database, which may cause the source database load to increase and add pressure to the database. If your database configuration is low, it is recommended to perform data migration during off-peak hours.

Impact on the Target Database

During migration, DTS is used along with the system service account to create a table named based on the task ID (such as dts-xxxxx) in the target TencentDTSData database. This table is used to record CHECKPOINT, enabling resumable transfer in case of task interruption.

Migration Architecture

1. The related instructions for shard migration are as follows:
1.1 Before a sharded cluster is migrated, it is recommended to clean up orphaned documents in the source cluster in advance. Otherwise, it may cause inconsistent data checks after migration. For how to clean up orphaned documents, see the MongoDB official documentation cleanupOrphaned.
1.2 During shard migration, do not enable sharding for the databases and tables under migration on the source to avoid inconsistent data distribution between the source and target. If sharding is enabled for the databases and tables under migration on the source during the process, check the shard status on the target. If sharding is not enabled on the target, manually enable it. For how to enable sharding, see the MongoDB official documentation Shard a Collection.
1.3 If the source is a sharded cluster that runs TencentDB for MongoDB 3.2, all shard keys are processed as hashed shard keys by default during migration. If you want to use ranged shard keys on the target, create the ranged shard keys in advance on the target before data migration.
2. Since single nodes do not support Oplog, incremental migration is not supported when the self-built instance is a single node.
3. For migrations of replica sets and sharded clusters that run MongoDB (version 4.2 and later), incremental migration supports capturing data changes through Change Stream.
4. For MongoDB sharded cluster migrations, using an SRV address to connect to the MongoDB database is supported

Must-Knows

Note:
When the source is AWS DocumentDB, and you choose the Change Stream migration method for incremental migration, you must enable Change Stream; otherwise, incremental data cannot be synchronized.
1. Do not perform the following operations during migration. Otherwise, they will cause the migration task to fail.
Do not modify or delete user information (including usernames, passwords, and permissions) and port numbers in the source and target databases.
Do not perform Oplog cleanup operations on the source database.
During the data migration phase, do not delete the target TencentDTSData database.
2. Exercise caution when operating on the target database data during the data migration phase to avoid data inconsistency.

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック