핵심 요약
- Six techniques, two questions: when a write counts as complete, and how the data moves between systems.
- TiKV replicates each Region across a Raft group. A write commits only after a majority of replicas confirm it, and Raft elects a new leader within seconds when one fails.
- Pick by RPO and RTO, not by feature list. Near-zero on both points to synchronous or transactional replication with automatic failover.
- Most production systems combine techniques rather than standardizing on one.
When a node in your database cluster fails at 2 a.m., what matters is whether a current copy of your data exists somewhere else, and whether your application can reach it without a human waking up to fix it. Data replication techniques answer that question, but the technique you choose determines how much data you can afford to lose, how much delay your writes can tolerate, and how much operational complexity your team takes on.
This guide covers the six replication techniques teams reach for most often: synchronous, asynchronous, snapshot, transactional, merge, and log-based. It also shows how 티DB, a distributed SQL database, implements replication under the hood using the Raft consensus protocol, and gives you a framework for matching a technique to your recovery point objective (RPO) and recovery time objective (RTO).
What Are Data Replication Techniques?
Data replication techniques are the methods a database uses to copy and synchronize data across multiple nodes, servers, or locations, so a failure in one place does not take your application down or lose committed data. Each technique makes a different tradeoff between consistency (how current every copy is), latency (how fast writes complete), and cost (how much compute, storage, and network bandwidth replication consumes).
The six techniques in this guide fall into two groups. Synchronous and asynchronous replication describe when a write counts as complete relative to its replicas. Snapshot, transactional, merge, and log-based replication describe how the data itself moves, whether as periodic full copies, transaction by transaction, in both directions between systems, or by streaming changes from a transaction log.
The next three sections cover all six in pairs, and the comparison table after them puts the tradeoffs side by side.
Synchronous and Asynchronous Replication: When a Write Completes
These two techniques split on a single question: does the primary wait for its replicas before telling the client the write succeeded?
Synchronous Replication
Synchronous replication mirrors every write onto all replicas before confirming it to the client. This keeps every copy of your data consistent at any given moment, at the cost of waiting for replica confirmation on every write. In financial systems where real-time data accuracy is critical, synchronous replication makes every node record the transaction identically before the application moves on. The tradeoff scales with distance: a replica in the next rack adds microseconds to every write, while a replica on another continent can add tens or hundreds of milliseconds, which is why synchronous replication usually stays within a single region or a small set of nearby data centers.
Asynchronous Replication
Asynchronous replication lets the primary confirm a write immediately and update replicas afterward. This cuts write latency and improves throughput, which suits systems like content delivery networks and e-commerce platforms where a few seconds of replica lag buys faster response times. Replicas may briefly diverge from the primary during that lag window, but they converge once the update propagates. The risk to plan for is a primary failure inside that window: the cluster loses any write that had not yet reached a replica, so teams choosing asynchronous replication need a defined tolerance for that loss rather than an assumption that it will not happen.
Snapshot and Transactional Replication: Copying on a Schedule or by Transaction
Both of these techniques move data from a primary to its replicas, but one works in scheduled batches and the other follows the transaction log change by change.
Snapshot Replication
Snapshot replication copies the entire database at a specific point in time, on a schedule rather than continuously. It works well for backups and reporting replicas where slightly stale data is acceptable, and it costs less than continuous replication because it only runs periodically. It does not support high availability: recovering from a snapshot means replaying everything that changed since the last capture, so the interval between snapshots effectively sets the maximum amount of data you could lose in a worst-case failure.
Transactional Replication
Transactional replication applies every change from the primary to its replicas in the same order it occurred, using a transaction log to track inserts, updates, and deletes. This keeps replicas strictly consistent with the source and suits systems handling financial transactions or order processing, where write order matters as much as write content. Because it preserves ordering, transactional replication also makes replicas useful as read-only copies for reporting without a separate export step.
Merge and Log-Based Replication: Two-Way Sync and Change Streams
The last two techniques handle cases the first four do not: multiple systems writing at once, and downstream systems that need changes as they happen.
Merge Replication
Merge replication lets two or more databases update independently and synchronize changes in both directions, with conflict resolution rules deciding what happens when the same record changes in two places at once. This suits collaborative environments, like a retail chain merging sales data from multiple store locations into a central database, but it demands more upfront planning around conflict resolution than one-directional techniques. Offline-capable applications rely on the same pattern: a mobile app that lets a user keep working without a connection runs a version of merge replication once the device reconnects and syncs its changes back.
Log-Based Replication
Log-based replication reads changes directly from the primary’s transaction log and applies them to replicas, without adding load to the primary through repeated full-table queries. It is efficient and low-latency, which makes it a common choice for real-time analytics pipelines and cross-region synchronization. Because it streams only the changes rather than re-reading whole tables, it also scales well as data volume grows, which is why most change-data-capture tools, including TiDB’s, use this pattern.
Comparing the Six Replication Techniques
Each technique solves a different combination of consistency, latency, and cost. This table puts those tradeoffs side by side.
| Technique | Consistency Model | Latency Impact | Best-Fit Use Case |
|---|---|---|---|
| Synchronous | Strong, all replicas match at commit | Higher, waits for replica confirmation | Financial transactions, zero-data-loss systems |
| Asynchronous | Eventual | Low, replica lag possible | CDNs, e-commerce reads, cross-region replicas |
| Snapshot | Point-in-time | Not continuous, batch-based | Backups, reporting replicas, infrequent-change data |
| Transactional | Strong, ordered by transaction log | Moderate | Financial systems, order processing |
| Merge | Eventual, conflict-resolved | Variable, depends on sync interval | Multi-writer collaborative systems, offline-capable apps |
| Log-based | Near real-time | Low, reads from log not primary | Real-time analytics, CDC pipelines, cross-region sync |
How TiDB Implements Data Replication
티DB is a distributed SQL database, and its storage engine, TiKV, implements a specific version of transactional and log-based replication using the Raft consensus protocol. Seeing how the two connect makes the abstract techniques above concrete.
TiKV divides data into Regions, contiguous ranges of key-value data. It replicates each Region to multiple TiKV nodes, typically three, and those replicas form a Raft group. One replica in the group serves as the leader; the others are followers. All reads and writes go through the leader, and a write only succeeds once a majority of the group’s replicas confirm it. This is why TiDB is strongly consistent rather than eventually consistent: the cluster does not acknowledge a transaction until enough replicas agree on it, which gives TiDB the same guarantee synchronous replication offers, one Region at a time.
Walk through what happens on a single write. A client sends an update to the Region leader. The leader appends the change to its Raft log and replicates that log entry to its followers. Once a majority, two out of three replicas in a typical setup, have persisted the entry, the leader commits it and returns success to the client. If the leader’s node fails before the group reaches that majority, the write never commits.
How TiDB Handles Failover and Downstream Replication
Raft handles failover itself. When followers stop receiving heartbeats from the leader, they hold an election and one of them becomes the new leader, so the Region keeps serving traffic without manual intervention. The Placement Driver (PD) plays a different role: it tracks store health across the cluster, re-replicates Regions that have dropped below their replica count, and rebalances Region leaders as load shifts so no single node stays a bottleneck for long. A cluster with thousands of Regions runs this process independently and continuously across every Raft group.
For downstream and cross-system replication, TiDB uses TiCDC, a change data capture tool that pulls change logs directly from TiKV nodes and replicates them to systems like Kafka or MySQL-compatible databases in real time. TiCDC streams changes rather than batching them: it sorts and merges them as they happen instead of running periodic extract-transform-load jobs, which keeps downstream replicas closer to current state and lightens the load on the source cluster.
TiDB also lets applications read directly from follower replicas instead of only the leader, a pattern TiDB calls follower read. This trades a small chance of reading slightly stale data for lower read latency and less load concentrated on the leader, which matters for read-heavy workloads spread across regions.
See the Region and Raft group diagram in TiDB’s storage documentation for the full picture of how these replicas relate to each other.
Choosing a Replication Technique: An RPO/RTO Framework
Picking a replication technique gets easier once you separate two questions: how much data can you afford to lose, your recovery point objective (RPO), and how long can you tolerate being down, your recovery time objective (RTO)?
If your RPO is close to zero, meaning you cannot lose a committed transaction, synchronous or transactional replication is the starting point: both confirm a write across replicas before treating it as durable. If your RPO tolerates a few seconds or minutes of lag, asynchronous or log-based replication trades a small consistency window for lower write latency and easier cross-region scaling.
RTO follows similar logic, but depends less on which technique you use and more on whether failover happens automatically. In TiDB, a Raft group elects a new leader on its own when the current leader stops responding, typically finishing failover in seconds without manual intervention, and PD re-replicates the affected Region afterward. Snapshot replication cannot hit a low RTO: restoring from a snapshot means replaying everything since the last capture, which can take minutes to hours depending on data volume.
As a starting point: pair synchronous or transactional replication with automatic failover, such as TiDB’s Raft-based leader election, when both RPO and RTO need to be near zero. Reach for asynchronous or log-based replication when cross-region latency matters more than sub-second consistency. Use snapshot replication as a backup layer underneath either approach, not as your primary high-availability mechanism.
Two Worked Examples: Fintech and Product Analytics
Consider a fintech company processing card transactions. Losing even one confirmed transaction is unacceptable, which puts its RPO at zero, and an outage longer than a few seconds risks tripping a regulatory SLA, which puts its RTO in the single-digit-second range. That combination points to transactional or synchronous replication within a Region, plus automatic failover. On TiDB, that means Raft groups with three replicas per Region and an automatic leader election on node failure, typically within seconds, without an on-call engineer promoting a replica by hand at 2 a.m.
Now compare that to a product analytics team building a dashboard on top of production order data. Losing a few seconds of the most recent events is tolerable since the dashboard already runs on a delay, which gives the team a much looser RPO, and a brief lag during failover will not page anyone, which loosens their RTO too. That profile favors log-based replication over synchronous: streaming changes from the transaction log keeps the dashboard current within seconds without adding write latency to the production path the way waiting for replica confirmation would.
Applications of Data Replication Techniques
The techniques above show up most often in two scenarios: recovering from a failure, and keeping analytics current without slowing down production. For four applied examples with named companies, including multi-region scale and AI agent state, see the companion guide to data replication strategies.
Disaster Recovery and Backup
Replication is the backbone of most disaster recovery strategies. Snapshot and transactional replication both provide a path back to a known good state after hardware failure, a cyberattack, or a regional outage, and the choice between them usually comes down to how much data loss the business can tolerate at the moment of failure. TiDB backs this with its disaster recovery solution, which combines snapshot backups with continuous Raft log replication, so a cluster can restore from a point close to the moment of failure rather than the last nightly backup. Because the cluster already replicates the Raft log for normal operation, disaster recovery does not require a separate replication pipeline on top.
Real-Time Analytics
Log-based and transactional replication keep analytics systems current without a separate batch pipeline. Trip.com uses TiDB to process real-time data and financial settlement at scale, relying on the same Raft-based replication above to keep transactional and analytical workloads consistent without a separate pipeline lagging behind production. That matters most in scenarios like fraud detection or pricing, where a decision that rests on data even a few minutes stale can already be the wrong decision.
Common Challenges in Data Replication
Replication solves availability and consistency problems, but it introduces its own tradeoffs to manage.
Data consistency and conflict resolution. As more nodes accept writes, keeping every replica in agreement gets harder, especially in merge replication, where two systems can update the same record at the same time. Teams typically resolve this with timestamp-based ordering or conflict-free replicated data types (CRDTs), both of which define a deterministic winner when writes collide. Getting this wrong shows up as replicas that quietly diverge, which is worse than an outage because nothing alerts you to it.
Latency and performance. Synchronous replication trades throughput for consistency: the primary waits for replica confirmation on every write, and that wait grows with the distance between nodes. A platform running synchronous replication across continents pays that round trip on every write. The usual fix reserves synchronous replication for the writes that cannot tolerate loss and moves everything else to asynchronous replication.
Security. Every additional replica is an additional copy of sensitive data in transit and at rest, which means an additional attack surface. A financial services company replicating customer records to a disaster recovery site needs to encrypt that traffic and audit access to the DR replica on the same schedule as the primary, not as an afterthought.
Data Replication Best Practices
Three habits separate a replication setup that holds up in production from one that only looks right on a diagram.
Match the technique to the requirement. Default to synchronous replication only where you cannot compromise consistency, log-based replication where near-real-time freshness matters most, and snapshot replication as a backup layer rather than a primary high-availability mechanism. Picking one technique for the entire system usually means over-paying for consistency in some places and under-protecting it in others.
Monitor continuously. Replication lag and failure rates need active monitoring, not an assumption that replicas stay in sync. A replica that silently falls behind defeats the purpose of replicating in the first place, and the failure mode is quiet: queries keep returning results, they are just old ones.
Encrypt and audit every replica. Apply the same encryption and access-control review to every copy of the data that you apply to the primary. Replication strategies that scale well on paper often skip this step for secondary or DR replicas, which is exactly where a breach is least likely to surface quickly.
Start From RPO and RTO, Not From a Feature List
Replication is rarely a single decision. Most production systems combine techniques: synchronous or transactional replication for the primary consistency guarantee, log-based replication for downstream analytics, and snapshot replication as a backup layer underneath both. None of these tools replaces the others, and picking just one because it is the most familiar option is how teams end up with a fast primary database and a disaster recovery plan that only works on paper.
To see Raft-based replication running in a live cluster, start with TiDB Cloud Starter, a free tier that runs the same Region and Raft group model this guide covers.
Data Replication Technique FAQs
What is Data Replication, and Why is It Important?
Data replication creates and maintains copies of data across multiple servers or locations. It keeps applications available when a single node or region fails, and it cuts read latency by serving requests from a nearby replica. It also underpins disaster recovery: a plan is only as good as its most recent restorable copy.
Which Data Replication Technique is Best for Real-Time Updates?
Log-based replication, in most cases. It streams changes straight from the transaction log with minimal lag and without re-querying whole tables on the primary. Transactional replication is a strong alternative when strict write ordering matters as much as freshness. In TiDB, TiCDC implements this pattern.
How Does Asynchronous Replication Differ From Synchronous Replication?
The difference is when a write counts as complete. Synchronous replication confirms a write only after replicas acknowledge it, favoring consistency over write latency. Asynchronous replication confirms immediately and updates replicas afterward, favoring throughput. If the primary fails inside that lag window, the cluster loses any writes that had not yet propagated.
How Does TiDB Implement Data Replication?
TiKV divides data into Regions and replicates each one across multiple nodes, typically three, as a Raft group. A write commits only after a majority of those replicas confirm it. When a leader fails, the remaining replicas elect a new one through Raft, usually within seconds, and PD re-replicates the Region afterward. TiCDC streams change logs to downstream systems.
How Do I Choose the Right Data Replication Technique?
Start with your recovery point objective: how much data loss you can accept. Then your recovery time objective: how much downtime you can accept. Near-zero on both points to synchronous or transactional replication with automatic failover. Higher tolerance for lag points to asynchronous or log-based replication.