Docs

Database Transmission Service

Data migration

MySQL database bidirectional synchronization

Database Transmission Service (DTS) supports MySQL database bidirectional synchronization. MySQL database bidirectional synchronization applies to multiple application scenarios, such as multi-site high availability (unitization) and cross-region data disaster recovery.

Bidirectional synchronization topology

Topology type	Topology diagram	Features
Single-write and multi-read		The key features for the single-write and multi-read architecture are as follows. The primary region is responsible for write services and asynchronously synchronizes the written data to other secondary regions. The secondary region provides read services. If there is data in a secondary region that needs to be written, it must be written through the primary region. The single-write and multi-read architecture is not suitable for services that are highly sensitive to reads and writes. Cross-region data transmission faces numerous issues and influencing factors, which can easily lead to latency. For businesses with high requirements for data read consistency, it is recommended to implement a cross-region callback mechanism in the primary region.
Multi-write and multi-read		The key features for the multi-write and multi-read architecture are as follows. It supports multi-region write and uses the data synchronization topology link for level-by-level synchronization. The overall data latency is related to the complexity of the topology. The more complex the topology, the greater the latency. The system adopts a unitized read/write mode. In general scenarios, business operations perform read and write activities within their local region, achieving a closed loop of read-write operations within the unit module. To avoid cross-region reads after local writes, data updated in other regions will be synchronized to the associated region through the synchronization link. The business side needs to allocate traffic to different regions according to specific <rules> (such as user ID distribution). You should avoid updating the same element in multiple regions. Accessing the same element needs to be routed to the corresponding unit. tip The multi-write and multi-read topology requires unitization transformation of businesses. For more information, refer to Business unit splitting.

Conflict resolution strategy

Conflict resolution strategy	Description	Recommendation level
Conflict overwrite	When source end data conflicts with destination data, the data from the source end overwrites the data from the destination. tip In most cases, the data obtained by selecting conflict overwrite is the data that the business wants, but there are also special cases. For example, in the bidirectional synchronization scenario of A and B, if the time A writes data is t1, and the time B writes data is t2 (t1 is later than t2), in the reverse link scenario of A, when the data of B is transmitted to A, it will overwrite the data written by A after t1.	Recommended first
Ignore on conflict	When the source end data conflicts with the destination data, ignore the conflict, and the source end and the destination write data respectively. tip Conflict ignore will cause data inconsistency between the source end and the destination.	Not recommended
Abort on conflict	When data conflicts occur between the source and target ends, you need to manually modify the conflict data; otherwise, the migration or synchronization task will pause and report an error. tip When a data conflict occurs, the data synchronization will pause. You need to manually resolve the conflict data, and the business verification passed before you can continue the migration or synchronization task. In this scenario, data consistency can be ensured, but the task pause will occur. Assume that an accident occurs in a certain end in an extreme scenario, and all subsequent data cannot be accessed.	Recommended only in the test environment

Bidirectional synchronization process

Create a MySQL bidirectional synchronization task

Precautions

In bidirectional synchronization of MySQL, do not perform DDL operations simultaneously on both the source and target database, or the synchronization task may fail. Bidirectional synchronization tasks only support synchronizing DDL operations from the forward task to the target database, and currently do not support synchronizing DDL from the reverse task. If you need to synchronize DDL operations from the reverse task, you can first adjust the DDL synchronization direction of the bidirectional synchronization task and then perform the DDL operations to ensure data consistency.

To ensure data consistency, it is recommended that rows with the same primary key value be updated in only one instance. If updated simultaneously, the system will handle it according to the primary key conflict handling method selected when configuring the data synchronization task.

In a bidirectional synchronization topology, you need to configure both a forward synchronization task and a reverse synchronization task separately. For configuration methods, refer to Configuring a forward task and Configuring a reverse task.

When performing OnlineDDL, forward compatibility must be ensured. For example, do not modify field types or reduce fields, as this may cause synchronization interruptions or data inconsistency. The forward-compatible table structure DDL list includes: create table, add column, modify column (increase field length), create index, and drop index.

It is not recommended to use public networks for bidirectional synchronization, as they are prone to performance bottlenecks.

Step 1: Create a synchronization task

You can select the corresponding reference documentation based on your source and target database types to create a data synchronization task.

When creating a bidirectional synchronization task, select Bidirectional synchronization as the synchronization topology. For more information, refer to Data synchronization topology.

Source database type	Source database version	Synchronization type	Target database type	Configuration documents
Volcano Engine RDS for MySQL	MySQL 5.7 MySQL 8.0	Full initialization Incremental synchronization Schema initialization	MySQL	Synchronizing to Volcano Engine RDS for MySQL Synchronizing to Volcano Engine veDB for MySQL Synchronizing to MySQL connected over public network Synchronizing to MySQL connected over express network
Volcano Engine veDB for MySQL	MySQL 8.0			MySQL	Synchronizing to Volcano Engine RDS for MySQL Synchronizing to Volcano Engine veDB for MySQL Synchronizing to MySQL connected over public network Synchronizing to MySQL connected over express network
MySQL connected over public network	MySQL 5.5 MySQL 5.6 MySQL 5.7 MySQL 8.0			MySQL	Synchronizing to Volcano Engine RDS for MySQL Synchronizing to Volcano Engine veDB for MySQL Synchronizing to MySQL connected over public network Synchronizing to MySQL connected over express network
MySQL connected over express network	MySQL 5.6 MySQL 5.7 MySQL 8.0			MySQL	Synchronizing to Volcano Engine RDS for MySQL Synchronizing to Volcano Engine veDB for MySQL Synchronizing to MySQL connected over public network Synchronizing to MySQL connected over express network

Step 2: Configure forward synchronization

After the bidirectional synchronization task is created, you can configure the data forward synchronization task via DTS. For more information, please refer to Configuring forward synchronization.

Step 3: Configure reverse synchronization

You can configure the reverse synchronization task after the forward synchronization task enters the incremental synchronization phase. For the configuration method, refer to Configuring reverse synchronization.

Traffic cutover

Before performing any traffic cutover, a bidirectional link must be established. Do not start, stop, or create DTS links during traffic cutover, as this may increase the complexity of the switchover and make the process uncontrollable.

During traffic cutover, write operations on the source end must be disabled to prevent concurrent business writes on both ends of the link at the same time.

Unidirectional traffic cutover

Normal cutover process	Abnormal cutover process
Confirm that the DTS latency is within 1 second. Disable writes on the source DB and confirm that DTS has no replication delay. Enable writes on the target DB.	Based on the DTS delay, decide whether to perform traffic cutover (prioritizing availability or accepting minor data inconsistency). Enable writes on the target DB.

Bidirectional traffic cutover

Normal cutover process

Abnormal cutover process

Confirm that the DTS latency is within 1 second.

Disable writes on the source DB and confirm that DTS has no replication delay.

Enable writes on the target DB.

For bidirectional synchronization, perform traffic cutovers in batches by user (Dual writes are generally cut over by user to ensure that the same user does not write on both sides at the same time).

Close the traffic write route of the user on the source end (User write will fail briefly).

Wait a few seconds, and the wait time is greater than the DTS delay time.

Change the user's traffic route on the Source end to the target DB.

Fault occurs

Network anomalies or datacenter failures in Region A result in a small backlog of data not being synchronized to Region B.

The business traffic of the source computer room drops, but not necessarily to 0.

Determine whether to switch traffic

Detects DTS latency, and DTS returns the latency status at the time of network disconnection.

Determine whether too much data is accumulated based on the latency status, and decide whether to perform an emergency traffic cutover.

Traffic cutover process

Disable writes on the source DB If the network is unreachable and disabling writes on the source DB fails, consider skipping this step (in which case the service can not be written).

Enable write restrictions for specific applications at the destination, such as order locking. For example, orders created in Region A should be prevented from triggering duplicate payment or shipment actions in Region B after traffic cutover.

Switch writes to Region B.

Check the application load and business success rate in Region B to determine if recovery is needed.

Appendix

Business unit splitting

Unitization refers to dividing businesses into small business units according to specific dimensions. Each unit covers all the services required by the business and can independently process the entire business process. Each unit stores only a portion of the data, and the complete dataset is formed by integrating the data from all units. A "unit" can be migrated as a relatively independent entity or partially deployed to a different geographical location.

The unitization of business components should adhere to the following principles to avoid data conflicts.

The use of database auto-increment IDs is prohibited. Third-party ID generators should be adopted instead.

It should be ensured that the data of each business unit is mutually independent, with minimal or no overlap.

A bidirectional link should be established from the read-write nodes at both ends, which may affect the read and write performance of the business.

Business unitization background

Existing pain points	After business unitization
Database connection bottleneck	Database connections are extremely valuable resources. After business unitization, data reads and writes within each unit form an internal closed loop, which helps reduce database connections.
Computer room latency	If unitization is well implemented, meaning that business access is strictly confined within its own unit. Data read/write in each unit is an intranet self-closed loop, without cross-computer room calls.
Traffic entry	Users are routed by the routing gateway, and each time they request the data center where they are located. For example, if a user is in center A, after unitization, user A's requests will be routed to center A and not to center B. The entire link, from ingress traffic to distributed services, eliminates single points of failure.
Data conflict	Users are grouped according to a rule, and each group of users can only write data to the specified data center. This is equivalent to binding users to the data center, which ensures that data from different user groups does not conflict before bidirectional synchronization.

Business unitization solution

Solution	Business scenario	Business unitization analysis
Solution 1	A customer is a logistics provider that provides logistics services for multiple e-commerce platforms such as taobao and jd.com. The key table, order table, and outline fields of its business are as follows. Order ID (OrderID) Order source (Platform) Logistics address (Address)	The customer stores orders from Taobao in Database A and orders from JD.com in Database B. In this case, a bidirectional synchronization link can be established between Database A and Database B. Since order changes (INSERT/UPDATE/DELETE) from Taobao originate solely from Database A, and order changes from JD.com originate solely from Database B, the data is naturally partitioned by "order source," preventing data conflicts.
Solution 2	A customer is a C‑end fitness app. Due to its massive user base, the customer uses Database A and Database B to store user data. The key fields of its User table are shown below. User ID (UserID) User information (UserInfo)	The user ID is a 32-bit string (containing only lowercase letters). The customer performs write partitioning operations at their user traffic entry. If the UserID starts with a to n, it is written to database A; if it starts with o to z, it is written to database B. At this time, a bidirectional synchronization link can be established to ensure that full user data can be read from either database A or database B. Given that user data starting with a to n will only be written to database A, and user data starting with o to z will only be written to database B, there will be no conflict in this bidirectional synchronization link.
Solution 3	A customer, an international B2B SaaS provider, writes data for domestic tenants to the CN database and data for international tenants to the US database. The tenant table is roughly as follows. Tenant ID (TenantID) Tenant name (TenantName) Tenant data (Data)	Customers can use DTS to establish a bidirectional synchronization link between the CN and US regions, ensuring that full data can be retrieved when reading from either database. In other words, read operations fetch the full data, while write operations are differentiated accordingly. Since data is written to CN or US entirely based on the tenant ID partition, no conflicts will occur.

Last updated: 2026.01.21 17:37:16