Updated on 2026-10-13 GMT+08:00

Cutover Process

Scenarios

After migrating a database from one instance to another, you need to switch the service over to the destination database. This section describes the cutover process at the time of switchover. This scenario applies only to one-way links with incremental synchronization.

Prerequisites

The data migration instance, including instances for real-time synchronization, real-time migration, and real-time disaster recovery tasks, is in the incremental running state. For configuration instructions, see the user guide for the corresponding link.

Overview

1. Stop Writes to the Source Database

To prevent data loss, pause writes to the source database to prevent new data generated on the source after the synchronization link is stopped from being synchronized to the target database.

2. Catch Up Data

After all required data has been synchronized from the source database to the destination database, confirm that the data on the two databases is consistent.

3. Reverse the Link

After the target database takes over the service, write subsequent incremental data back to the source database in a timely manner to enable safe rollback.

4. Switch Over the Service

Enable writes to the target database and resume the service.

Precautions

Because database writes must be stopped during the cutover, perform the operation during off-peak hours to minimize the impact.

Once a task is ended, billing stops and the resources are released. The task cannot be resumed. Therefore, during the cutover, determine whether to pause or end the task, or use the real-time disaster recovery feature.

Before and after the cutover, ensure that data is written to only one end at a time. Otherwise, service data may not be synchronized to the other end, resulting in data inconsistency.

Procedure

Wait for the migration to complete. Wait until the DRS task enters the incremental migration stage and the latency remains below 5 seconds for at least 5 minutes.
Pause service writes.
1. Temporarily stop service writes to prevent new data from being written to the source database. You can set the source database to read-only and, if necessary, terminate sessions or revoke write permissions.
2. Log in to the source database and repeatedly query the position to confirm that it no longer changes, or ensure that no new service data is being written.
  For MySQL, run the following command to view the position:
  
  show master status;
  
  If heartbeat data or other unrelated writes cause the position to change, run the following command to confirm that no normal service writes have occurred after the position was checked:
  
  show binlog events in 'xxx' from yyy;
Wait for the data to catch up.
1. On the task progress page, check that Source Position and Consumed Position are the same. If necessary, verify that they match the position returned by show master status; on the source database.
2. Compare the data to ensure that the data on the source and target databases is consistent. You can create a data comparison task on the data verification page and wait for the comparison result to show that the data is consistent.
  
  If a content comparison takes too long, you can select row comparison. Alternatively, select some core tables, configure query conditions, and perform a spot check of some data.
Prepare the reverse link.

For Real-Time Disaster Recovery tasks, perform primary/standby switchover.

For Real-Time Synchronization or Real-Time Migration tasks, you can:
1. Pause or end the task.
  
  When you pause a task, information such as events and triggers is not migrated. If this information needs to be migrated, end the task instead.
2. Create a reverse one-way incremental task and wait until the task enters the incremental running state.
Connect the service to the destination database.
1. Connect the service to the destination database and enable writes.
2. Verify the service.