When you deploy applications and databases across regions or availability zones for disaster recovery and nearest access, a core challenge is handling data conflicts that result from simultaneous writes. Global Distributed Network (GDN) provides an active-active pattern to address this issue. It supports bidirectional data writes between the primary and secondary instances, which lets you build an active-active database service in two locations. This improves business continuity and the user access experience. To ensure data consistency during bidirectional writes, you must understand and configure the core Data Definition Language (DDL) synchronization rules and data conflict handling policies.
Scope
Before you use the GDN active-active pattern, ensure that your business scenario and technical architecture meet the following conditions:
Architecture limits: Only a one-primary, one-secondary active-active architecture is supported.
DDL operation limits: All DDL operations, such as creating or modifying a table schema, must be executed on the primary instance. Do not execute DDL operations on the secondary instance. If you do, data synchronization errors will occur.
DDL synchronization rules
DML synchronization: Bidirectional synchronization. Data Manipulation Language (DML) operations, such as
INSERT,UPDATE, andDELETE, that are executed on either instance are synchronized to the other instance.DDL synchronization: One-way synchronization. Only table schema changes, such as
CREATE/ALTER TABLE, that are executed on the primary instance are synchronized to the secondary instance. The primary instance serves as the single point of entry for schema evolution to ensure structural consistency across the cluster.
Data conflict handling policies
Data conflicts occur when the primary and secondary instances simultaneously receive write requests for the same unique key (UK). When you create an active-active instance, you can specify a conflict handling policy that defines how the database automatically resolves these conflicts.
This policy applies only to DML operations such as INSERT, UPDATE, and DELETE. DDL operations such as CREATE/ALTER TABLE still follow the one-way synchronization rule.
Conflict policy | Description | Scenarios |
INTERRUPT (Break synchronization) | When a unique key conflict occurs, data synchronization stops immediately and waits for manual intervention. | For services that require extremely high data consistency and precise auditing of conflicts, such as financial trading systems. |
IGNORE (Ignore conflict) | When a unique key conflict occurs, the write operation from the source instance is ignored, and the existing data on the destination instance is retained. | For non-core services that can tolerate minor data discrepancies, such as log records. |
OVERWRITE (Overwrite conflict) | When a unique key conflict occurs, the data from the source instance overwrites the existing data on the destination instance. | For services that need to retain the latest written records, such as user status updates and cache prefetching. |
DIRECT_OVERWRITE (Force overwrite) | This policy uses | For scenarios that require forcing data unification, such as data correction and order status synchronization. |
Best practice recommendations
INTERRUPT (Break synchronization): Use a comprehensive monitoring and alerting system to ensure that you are promptly notified and can take action if synchronization stops.
OVERWRITE (Overwrite conflict)/DIRECT_OVERWRITE (Force overwrite): To prevent overwrite operations from causing unexpected results, implement an idempotent design at the business logic layer.
IGNORE (Ignore conflict): Before you use this policy, carefully evaluate your service's tolerance for data loss. This policy should be used only for tables of non-core services.