Global Distributed Network (GDN) supports bidirectional writes between a primary and a secondary instance, letting you build an active-active database service across two regions or availability zones. This improves business continuity and reduces latency for end users. To keep data consistent during bidirectional writes, you need to understand two things: which operations are subject to the one-way DDL synchronization rule, and how the system resolves write conflicts when both instances receive a request for the same row at the same time.
Scope
GDN's active-active pattern supports a one-primary, one-secondary topology only.
DDL synchronization rules
GDN applies different synchronization rules to Data Manipulation Language (DML) and Data Definition Language (DDL) operations:
DML (INSERT, UPDATE, DELETE): Bidirectional. Operations executed on either instance are synchronized to the other.
DDL (CREATE TABLE, ALTER TABLE, and similar schema changes): One-way, from primary to secondary only. The primary instance is the single point of entry for schema evolution.
Run all DDL operations on the primary instance. If you execute DDL on the secondary instance, data synchronization errors will occur.
This restriction exists because DDL and DML operations targeting the same object, routed through different nodes, can produce structural inconsistencies before replication completes. Treating the primary instance as the sole DDL entry point eliminates this risk.
Data conflict handling
Conflicts occur when the primary and secondary instances simultaneously receive write requests for the same unique key (UK). GDN resolves these conflicts automatically according to the policy you select when creating the active-active instance.
Conflict policies apply to DML operations (INSERT, UPDATE, DELETE) only. DDL operations continue to follow the one-way synchronization rule regardless of the selected policy.
Conflict policies
| Policy | Behavior | When to use |
|---|---|---|
| INTERRUPT | Stops synchronization immediately on a unique key conflict. Requires manual intervention to resume. | Services that require strict data consistency and a full audit trail for every conflict, such as financial trading systems. |
| IGNORE | Keeps the existing data on the destination instance and discards the conflicting write from the source. | Non-critical services that can tolerate occasional data discrepancies, such as log records. |
| OVERWRITE | Overwrites the destination data with the source data on a unique-key conflict. | Services that need the most recently written value to win, such as user status updates and cache prefetching. |
| DIRECT_OVERWRITE | Uses REPLACE INTO semantics to force the source data to overwrite the destination. | Scenarios that require forcing data unification, such as data correction and order status synchronization. |
Best practices
INTERRUPT
Set up a comprehensive monitoring and alerting system so you are notified immediately when synchronization stops.
OVERWRITE and DIRECT_OVERWRITE
Design idempotent writes at the business logic layer. When an overwrite policy is active, the same write may be applied more than once if retries occur. Idempotent logic ensures the result is the same regardless of how many times the write executes.
IGNORE
Evaluate your service's tolerance for data loss before selecting this policy. Use it only for tables in non-critical services where occasional data discrepancies are acceptable.