Operation Guide

Prerequisites

• There is a DDM instance with available schemas.
• There is an RDS for MySQL instance in the same VPC as the DDM instance, and is not associated with any other DDM instances. If adding data nodes is required, ensure that the new data nodes are in the same VPC as the DDM instance.
• The kernel version of the DDM instance must be 3.0.8.3 or later. The latest kernel version is recommended.
• Ensure that the instances to be associated with your schema cannot be in read-only states.
• Unsharded schemas do not support shard configuration.

Procedure

1. Log in to the DDM console.
2. In the instance list, locate the instance that you want to configure shards for and click its name.
3. On the displayed page, choose Schemas to view schemas of the DDM instance.
4. In the schema list, locate the schema that you want to configure shards for and click Configure Shards in the Operation column.
   Figure 1 Configuring shards
   

5. On the Configure Shards page, configure the required parameters and click Test Availability.
   Figure 2 Configuring shards
   

   Table 1 Parameter description

   Parameter	Description
   Current DB Instances and Shards	Displays the information of current DB instances and shards.
   Total Shards After Configuration	Defaults to the total number of existing shards in the schema. If you want to increase shards, change the default value to the new total number of shards, and DDM will distribute all shards evenly to all data nodes.
   Execution Node Type	The default value is Shared. You can change the execution node type based on service requirements. Shared: The node is responsible not only for configuring shards, but also for handling service requests. So, shard configuration is slower. Dedicated: The execution node will be dedicated to configuring shards, so shard configuration is faster. If you are worried about not having enough nodes to handle your services, add more nodes before configuring shards. If you select Dedicated for the execution node type, enable load balancing for the default group and ensure that the number of nodes exceeds one.
   Route Switchover	Both manual and automatic switchover are supported. Read and write requests involved will be switched to new DB instances. During the switchover, one or two intermittent disconnections may occur but do not affect your services. You are advised to perform the switchover during peak-off hours.
   DB Instance	An existing instance is selected by default. You can determine whether to add DB instances based on service requirements. You need to input the required password for testing connectivity. Only after the connectivity test is successful, you can go to the next step.

   

   • Tables without primary keys do not support shard configuration.
   • The number of physical shards per data node in the schema cannot exceed 64. If more than 64 shards are required, contact DDM customer service.
   • Required permissions: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, PROCESS, REFERENCES, INDEX, ALTER, SHOW DATABASES, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER WITH GRANT OPTION

6. After the test is successful, click Next to go to the Precheck page.
   Figure 3 Pre-check
   
   

   • Precheck is not the start of shard configuration. The configuration task does not start until you click OK.
   • Handle risks first if any. You can also ignore the risks if you ensure that they do not affect your services.

7. After all check items are complete, click Configure shards.
   • The shard configuration task is in progress. A data migration task is performed in two phases, full migration and increment migration, respectively.

     You can view the migration progress on the Task Center page.

     You can click next to the task to view task details, including shards and data nodes before and after the shard configuration, and switchover policy.

     Figure 4 Viewing progress of a shard configuration task
     
     You can run show migrate status on a SQL client to view progress of the shard configuration task.

     Figure 5 Running the required command to view task progress
     

     

     The number of returned records corresponds to the number of source RDS instances.

     SOURCE_RDS: indicates the source RDS instance.

     MIGRATE_ID: indicates the ID of the task of configuring shards.

     SUCCEED_TABLE_STRUCTURE: indicates the number of physical tables whose structure data has been migrated.

     TOTAL_TABLE_STRUCTURE: indicates the total number of physical tables whose structure data is to be migrated.

     SUCCEED_TABLE_DATA: indicates the number of physical tables whose data records have been migrated.

     TOTAL_TABLE_DATA: indicates the number of physical tables whose data records are to be migrated.

     SUCCEED_INDEX_DATA: indicates the number of physical tables whose indexes have been migrated.

     TOTAL_INDEX_DATA: indicates the number of physical tables whose data records are to be migrated.

     FULL_SUCCEED_COUNT: indicates the objects that have finished a full migration in the current scale-out subtask.

     FULL_TOTAL_COUNT: indicates all objects that need to be migrated by a full migration in the current scale-out subtask.

     FULL_PERCENTAGE: indicates the percentage of migrated objects in the full migration in the current scale-out subtask.

     Aggregate total objects to be migrated in a full migration and migrated objects in each scale-out subtask. The total objects to be migrated and migrated in all subtasks are displayed in the progress bar at Task Center.

   • On the Task Center page, choose More > Modify Switch Policy in the Operation column.
     Figure 6 Modifying switch policy
     
   • On the displayed page, click More > View Log in the Operation column to view task logs.
     Figure 7 Viewing logs
     
   • If you select Manual for route switchover, click Switch Route at Task Center after data is completely migrated. If you select Automatic, the route is automatically switched over within the specified time.
     Figure 8 Manual switchover
     
     

     • Switching route is critical for a shard configuration task. Before the route is switched, you can cancel a shard configuration task, and data in original databases is not affected.
     • If a new RDS for MySQL instances is added, write operations will be disabled during route switchover. If the number of shards is increased, read and write operations are both disabled during route switchover.
     • Switching route during off-peak hours is recommended. This is because data validation is required during this process, increasing the switchover time. How long route switchover requires depends on the volume of the data involved.

8. Click Clear in the Operation column to delete the data migrated from original RDS for MySQL instances.
   Figure 9 Clearing data
   

9. Carefully read information in the dialog box, confirm that the task is correct, and click Yes.
10. Wait till the source data is cleared.
    Figure 10 Old data deleted successfully
    
    

    Old data can be deleted by the DROP statement. After the deletion, storage space may not be released immediately due to MySQL constraints.

11. Run the following commands after the shard configuration is complete:

    show data node: used to view the relationship between new data nodes and shards.

    show db status: used to view the estimated usage of schema disks.