Constraints and Operation Suggestions on Many-to-One Scenario

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.
• In the many-to-one synchronization scenario, value comparison is not recommended because data consistency cannot be ensured.
• 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: Instance-level Many-to-One Data Migration

Data migration aims to migrate the entire database. Multiple databases can be migrated at the instance level (for example, migrating data from source 1, 2, and 3 to the destination database in Figure 2). Databases with the same name in the source system cannot be migrated and database name mapping is not supported.

Figure 2 Many-to-one data migration

Scenario 2: Many-to-One Real-Time Synchronization

Unlike data migration, real-time synchronization maintains continuous data flow between different services. In addition to instance-level many-to-one synchronization (for example in Figure 3, data synchronization from the financial system and order system to the reporting system), it can also use object name mapping to enable many-to-one synchronization of database-level or table-level data (for example in Figure 3, synchronization of data from table B in the financial system and order system to table B in the reporting system).

Figure 3 Many-to-one synchronization

Instance-Level Many-to-One Task Operation Process

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

Figure 4 Flow chart

Database/Table-Level Many-to-One Task Operation Process

During real-time synchronization, you can use object name mapping to change the names of databases and tables to enable database/table-level many-to-one synchronization.

The following uses database-level many-to-one synchronization as an example:

1. On the Set Synchronization Task page, select the database that needs to be mapped from the synchronization objects on the right area and click Edit.
2. In the displayed dialog box, enter a new database name. The new database name is the name of the database saved in the destination DB instance.

   For example, after you change database A and database B in the source DB instance to database C, data can be synchronized from database A and database B to database C in real time.

3. After the database name is changed, the database name before modification and the new database name are displayed. The database mapping is complete.
   Figure 5 Checking the result
   

4. Wait until the task is started and the synchronization is complete.