Which Operations on the Source or Destination Database Affect the DRS Task Status?

Take RDS for MySQL as an example. The following operations may affect the DRS task status.

• Backing up an instance: Generally, backing up an instance has no impact on DRS tasks.
• Changing the single-node mode to the primary/standby mode: In normal cases, DRS tasks are not affected.
• Restarting an instance: Restarting an instance will cause a temporary interruption. During this period, the DB instance is unavailable and the DRS connection is interrupted for a short time. In this case, DRS automatically retries. If the failure persists, click Resume in the Operation column to resume the task after the instance becomes normal.
• Primary/standby switchover: During a primary/standby switchover, services may be intermittently interrupted for several seconds or minutes. In this case, DRS automatically retries. If the failure persists, click Resume in the Operation column to resume the task after the instance becomes normal.
• Changing specifications: After instance specifications are changed, the instance will be restarted, which will cause temporary interruption. During this period, the DB instance is unavailable and the DRS connection is interrupted for a short time. In this case, DRS automatically retries. If the failure persists, click Resume in the Operation column to resume the task after the instance becomes normal.
• Upgrading the version of a DB instance: Upgrading the minor version of a database kernel will restart the DB instance. Restarting the DB instance will cause temporary interruption. During this period, the DB instance is unavailable and the DRS connection is interrupted for a short time. In this case, DRS automatically retries. If the failure persists, click Resume in the Operation column to resume the task after the instance becomes normal.
• Abnormal instances: If a DB instance becomes abnormal, DRS automatically retries. If the failure persists, click Resume in the Operation column to resume the task after the instance becomes normal.
• Restricting the number of connected sessions: A certain number of sessions are required for a DRS task to connect to the source and destination databases. For details, see How Does DRS Affect the Source and Destination Databases?. If the number of connections is insufficient, the DRS task fails. You can adjust the number of database connections and click Resume in the Operation column to resume the task.
• Network jitter: If the DRS connection fails due to network jitter, DRS automatically retries. If the failure persists, click Resume in the Operation column to resume the task after the network recovers.
• Changing passwords: Changing a database password may cause DRS connection failures. For details, see What Do I Do After Changing the Password of the Source or Destination Database?.
• Changing permissions: Changing database account permissions may cause data migration failures due to insufficient DRS permissions. After assigning permissions to the migration account again, click Resume in the Operation column to resume the task.
• Clearing source database logs: When source database logs (for example, MySQL binlog) are cleared, DRS cannot obtain logs that connect to the current synchronization position from the source database. As a result, the task may fail (for example, Full or Incremental Phase Error: binlog is not existed). Reset the synchronization task by referring to , or create a synchronization task again.
• Changing database parameters: DRS pre-checks the source and destination database parameters before starting a task. Do not modify the database parameters after the pre-check is complete. Otherwise, the task may fail. If the task fails due to parameter changes, restore the parameters and click Resume in the Operation column to resume the task.