Global Database Network (GDN) DML replication captures data changes from binary logs and replays them on downstream clusters. A GDN supports four replication policies so you can balance performance, transaction consistency, and latency based on your workload.
Replication policies
SPLIT is the default policy. The following table compares all four policies.
| Policy | Performance | Transaction consistency | Best for |
|---|---|---|---|
| SPLIT (default) | High | Low | Workloads without cross-row data dependencies |
| TRANSACTION | Moderate | High | Workloads requiring strict transactional integrity, such as financial applications |
| SERIAL | Moderate | Low | Workloads with table-level ordering requirements, such as foreign key or business-order constraints |
| MERGE | High | Low | High-throughput workloads where change type and transaction boundaries are not critical |
SPLIT
SPLIT uses parallel replication with row-level parallelism. Data in different tables or with different primary keys is distributed across separate execution threads, maximizing write throughput.
Transaction integrity is not guaranteed: a transaction in the binary log may be applied as multiple independent changes on the downstream cluster. Use SPLIT when data dependencies between rows are absent and eventual consistency is acceptable.
TRANSACTION
TRANSACTION uses serial replication and preserves transaction boundaries end-to-end. All changes within a transaction are applied atomically on the downstream cluster, making it suitable for workloads where a recovery point objective (RPO) greater than 0 is acceptable but transaction integrity cannot be compromised.
Transaction integrity is only guaranteed in single-stream binary log replication mode. Multi-stream binary log mode improves parallelism but does not preserve transaction boundaries. Parallel replication between transactions without data conflicts is not supported.
Replicating extremely large transactions may introduce a short latency spike on the replication link. The latency scales with transaction size and commit time.
SERIAL
SERIAL uses serial replication without transaction integrity guarantees. Each data change is auto-committed as a standalone transaction, so no distributed transaction is triggered.
SERIAL is suitable when table-level ordering is required — for example, when foreign key constraints or business-order constraints exist between tables. Because each change is committed independently, SERIAL generally outperforms TRANSACTION. The two policies produce similar performance only when each binary log transaction contains exactly one data change.
MERGE
MERGE uses parallel replication with change compression and batch writing. Data is batch-processed per table, enabling full parallelism and high write throughput.
Change types and transaction boundaries are not preserved. Use MERGE when data dependencies are absent and your downstream consumer is insensitive to whether changes arrive as inserts, updates, or deletes.
Usage notes
Tables without primary keys can be replicated, but duplicate rows may be written to the downstream cluster.
When using TRANSACTION, replicating extremely large transactions may cause a short latency spike proportional to the transaction size and commit time.