Constraints and Operation Suggestions on Many-to-One Scenario
DRS supports many-to-one scenarios during migration or synchronization of different types of instances and tables to suit your service requirements.
Operation Suggestions
- To ensure that there is sufficient space during task creation, you are advised to calculate the total data volume of the source database and plan how to allocate the disk space of the destination instance. The remaining disk space must be greater than the total data volume of the source database. For example, if the data volume of source system1 is 1 GB, the data volume of source system2 is 3 GB, and the data volume of source system3 is 6 GB, the remaining disk space of the destination instance must be greater than 10 GB.
- To improve the performance of the destination MySQL database, you are advised to use the Save Change function to configure common parameters (except max_connections). For performance parameters, you need to manually change the parameter values based on the specifications of the destination database.
- When you create a many-to-one synchronization task, the task created later may block the task created earlier. This is because each synchronization task involves index creation. When an index is created, a schema lock may occur on the destination database, which blocks the synchronization of other tables in the schema. As a result, the previously created tasks cannot be synchronized. To avoid this problem, you are advised to set Start Time to Start at a specified time to start a task during off-peak hours.
- For many-to-one synchronization tasks that involve the synchronization of the same table, DDL operations cannot be performed on source databases. Otherwise, all synchronization tasks fail.
Figure 1 Parameter comparison
Scenario 1: Many-to-One Data Migration
Data migration aims to migrate the entire database. Multiple databases can be migrated at the instance level. Databases with the same name in the source system cannot be migrated and database name mapping is not supported.
Scenario 2: Many-to-One Real-Time Synchronization
Unlike data migration, real-time synchronization maintains continuous data flow between different services. It supports table-level, many-to-one synchronization and database-level mapping.
Flow Chart
When creating a task, ensure that the second task is created after the first task has entered the full migration state. For details, see Overview
General Operations FAQs
- What Can I Do When Information Overlaps on the DRS Console?
- Is the Destination Instance Set to Read-only or Read/Write?
- How Do I Set Global binlog_format=ROW to Take Effect Immediately?
- How Do I Set binlog_row_image=FULL to Take Effect Immediately?
- How Do I Change the Destination Database Password to Meet the Password Policy?
- How Do I Configure the Shard Key for a MongoDB Sharded Cluster?
- Does Bandwidth Expansion Affect the Running DRS Tasks?
- Why Data in MariaDB and SysDB Cannot Be Migrated or Synchronized?
- Constraints and Operation Suggestions on Many-to-One Scenario
- Constraints and Operation Suggestions on One-to-Many Scenario
- Where Can I View DRS Operation Logs?
- Why Is a DRS Task Automatically Stopped?
- How Can I Export a DRS Task List?
- Can a Completed Task Be Restarted?
- What Are the Differences Between Resetting a Task and Recreating a Task?
- Does DRS Support Backward Migration/Synchronization?
- Why Cannot I Select an Existing SMN Topic?
- Can I Change an SMN Topic After a Task Is Created?
- Will Data of DRS Tasks Be Lost After a Primary/Standby Switchover Occurs on the Source MySQL Database?
- What Are the Differences Between All, Tables, and Databases During DRS Object Selection?
- What Do I Do After Changing the Password of the Source or Destination Database?
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.
more