Should I Create a DRS Task on the Source Database or Destination Database?

How DRS Works

DRS sends a log request to the source database to capture incremental logs. Each request retrieves a large amount of incremental data, allowing a large volume of data to be obtained with a single TCP synchronization interaction.

When DRS synchronizes data to the destination database, it uses JDBC to execute SQL statements. New connections are established periodically. Each transaction begins with initiating the transaction, followed by writing a small batch of data, and concludes with committing the transaction. This process involves three TCP synchronization interactions to replay a small amount of data.

DRS Task Duration Calculation and Comparison

Assume that there is a synchronization task from MySQL to MySQL. In a long-distance or high-latency environment, if the network delay is 100 ms, each TCP synchronization interaction involves the client sending a request to the server and the server responding with data or status.

All incremental data can be retrieved in a single log capture request. If there are 10 MB of logs and the bandwidth is 10 MB/s, the theoretical time required based on the log capture duration formula is as follows:

Figure 1 Log capture duration

When writing data to the destination database, each transaction requires three interactions. Assuming an average transaction size of 1 KB, if there is 10 MB of data and the bandwidth is 10 MB/s, the theoretical replay duration with 64 threads is as follows:

Figure 2 Data replay duration

However, the TCP sliding window and congestion control algorithms may impact log capture, potentially extending the log capture duration beyond 1.1 seconds, for example, to 2 to 3 seconds. Data replay is only slightly affected, as the replay duration is 46 seconds or longer.

When using DRS for long-distance data synchronization, deploy DRS close to the destination database. If DRS is deployed on the cloud, create a to-the-cloud task.