An order written in Singapore needs to appear in a Frankfurt reporting database seconds later, in the right order, with no half-applied transactions. Cross-region sync breaks in exactly those three places: delay, ordering, and partial writes. 티DB handles all three with two mechanisms that work as a pair. Multi-version concurrency control (MVCC) gives every committed change a timestamp, and TiCDC, TiDB’s change data capture tool for global sync, streams those changes to other regions in timestamp order.
How Does TiDB Keep Data in Sync Across Regions?
TiDB keeps data in sync across regions with MVCC and TiCDC. MVCC lets reads and writes run concurrently without blocking by keeping multiple timestamped versions of each row, and TiCDC streams committed changes to clusters or systems in other regions in commit-timestamp order. Between separate TiDB clusters, TiCDC replicates with second-level recovery point objective (RPO) and minute-level recovery time objective (RTO).
What Makes Global Data Synchronization Hard
Global data synchronization keeps data consistent and accessible across data centers on different continents. Two forces work against it.
- Network latency. Round trips between continents add tens to hundreds of milliseconds, so every update reaches remote regions later than it reaches local ones.
- Consistency under failure. When a network partition or node failure interrupts replication, the receiving side can end up with partial transactions or changes applied out of order.
A sync design has to answer both questions: how fresh remote data needs to be, and what guarantees hold when the link drops.
How MVCC and TiCDC Work Together for Cross-Region Sync
MVCC and TiCDC split the problem cleanly. MVCC handles concurrent access within a cluster, and TiCDC propagates committed changes across regions using the timestamps MVCC already assigns.
MVCC: timestamped versions inside the cluster
TiKV, TiDB’s storage layer, never overwrites a row in place. Each write adds a new version keyed by the transaction’s commit timestamp, which comes from the timestamp oracle (TSO) in the Placement Driver (PD). A reader picks a start timestamp and sees exactly the versions committed before it, so reads never block writes and never see half-committed transactions. Old versions remain until garbage collection removes them.
TiCDC: ordered changes between regions
TiCDC listens to the Raft log of every Region in the upstream TiKV cluster, so it captures each committed change with its commit timestamp attached. It sorts changes by that timestamp and writes them to downstream targets through replication tasks called changefeeds. Targets include another TiDB cluster, MySQL, Kafka, and storage services. A resolved timestamp marks the point before which every change has been delivered, so a downstream consumer knows its copy is complete up to that moment.
The two mechanisms compound. MVCC already stamps every change with a cluster-wide commit order, so TiCDC does not have to reconstruct ordering from separate per-node logs. Downstream regions receive changes in the order they committed upstream.
tiup cdc cli changefeed create \
--server=http://10.0.10.25:8300 \
--sink-uri="mysql://root:password@10.1.0.10:4000/" \
--changefeed-id="sg-to-fra"For cross-region links above 100 ms, deploy TiCDC in the upstream region on TiCDC v6.5.2 and later. Earlier versions should run in the downstream region instead. The TiCDC documentation covers sink options and changefeed management in full.
Autohome put TiCDC into production after moving its applications to TiDB. The team replaced MySQL binlog with TiCDC for replication and built a Kafka output on top of it to move high-volume data into downstream systems.
Global sync on TiDB rests on one design decision. Every change carries a commit timestamp. MVCC uses it to keep reads consistent, and TiCDC uses it to deliver changes to other regions in order.
See MVCC in action on your own data. Start free with TiDB Cloud Starter, then use the TiCDC documentation to plan cross-region changefeeds for production.
Frequently Asked Questions About TiDB Global Data Sync
What is TiCDC and how is it different from generic CDC?
TiCDC is TiDB’s native change data capture tool. Generic CDC tools read a database’s binary log from a single server, which fits a single-node database like MySQL. TiDB has no single log, because its data is spread across many TiKV Regions, each with its own Raft log. TiCDC reads those Raft logs directly, sorts changes by commit timestamp across the whole cluster, and outputs them to TiDB, MySQL, Kafka, or storage, with resolved timestamps that mark delivery progress.
Does MVCC affect write performance in TiDB?
MVCC adds little cost to an individual write, because a write appends a new version instead of updating a row in place. The cost appears later, as old versions accumulate and scans must skip past them. Garbage collection removes versions older than tidb_gc_life_time, 10 minutes by default. Raising that value keeps more history for long-running queries and increases scan work, so set it to the shortest window your workload needs.
How fast does data propagate between regions with TiCDC?
For TiDB-to-TiDB replication, TiDB documents second-level RPO and minute-level RTO, so a downstream cluster trails the upstream by seconds in normal operation. Lag tracks downstream write speed more than network distance. In a tuning example in the TiDB documentation, changefeed checkpoint lag stayed within 500 ms once the downstream cluster could keep up with the write load. Watch the Changefeed checkpoint lag metric, measured in seconds, to see real propagation time.
What is the difference between this guide and TiDB’s multi-region deployment guide?
This guide covers how data stays synchronized between separate TiDB clusters and downstream systems, using MVCC and TiCDC. TiDB’s multi-region deployment guide covers one cluster stretched across regions, configured with labels and placement rules, where Raft keeps every replica consistent. Use a stretched cluster when you need synchronous consistency across regions. Use TiCDC between clusters when each region can run independently and accept seconds of replication lag.