All Products
Search
Document Center

ApsaraDB RDS:Use DTS to perform vertical splitting on an ApsaraDB RDS instance

Last Updated:May 16, 2023

If your ApsaraDB RDS instance is overloaded, you can vertically split a database or table from the RDS instance into another RDS instance. This topic describes how to use the dual-write solution and simple splitting solution to perform vertical splitting on an RDS instance.

Background information

Assume that your RDS instance contains Database A and Database B. If the RDS instance reaches its maximum performance due to business growth and you want to offload the workloads on the RDS instance, you can vertically split Database B into a different RDS instance. For more information, see the "Dual-write solution" and "Simple splitting solution" sections of this topic.

Usage notes

  • You must create another RDS instance into which you want to split databases or tables of your RDS instance. Make sure that the permissions required for database accounts of the destination RDS instance and the source RDS instance are the same. For more information about the database engines that are supported by the destination RDS instance, see Overview of data migration scenarios.

    Note

    We recommend that you create a database account for the source and destination databases and grant permissions that are required for data migration to the database account. This facilitates session distinguishing and enhances data security.

  • You must add the endpoint of the destination RDS instance to your application.

  • If you use the simple splitting solution, you must suspend your service for a short period of time and temporarily stop writing data to the database that you want to split. To reduce negative impacts that are caused by application changes and releases and switchovers between RDS instances during vertical splitting, we recommend that you use the simple splitting solution during off-peak hours. For more information, see the "Simple splitting solution" section of this topic.

Dual-write solution

Note

The dual-write solution helps implement phased switchover and reduce negative impacts on your service. Before you use the dual-write solution, you must modify your application and make sure that the application data can be written to Databases B of the source and destination RDS instances.

  1. Configure a data migration task for the source and destination RDS instances. For example, Database B in the source RDS instance is the database that you want to migrate. For more information, see Overview of data migration scenarios.

    Note

    When you configure the data migration task, you must select Schema Migration, Full Data Migration, and Incremental Data Migration.

  2. Wait until the task progress bar shows "Incremental Data Migration" and "The migration task is not delayed" or a delay time of less than 5 seconds.

    Data migration task 1 (Forward)
  3. Check whether the data in Databases B of the source and destination RDS instances is consistent.

  4. If the data is consistent, stop the data migration task. For more information, see Stop a data migration task.

    Warning

    The database accounts that are used for data migration are granted the read and write permissions. After the data migration task is complete, you must delete the accounts or revoke the write permissions of the accounts to ensure data security.

  5. Write the application data to Databases B of the source and destination RDS instances.

  6. Log on to Databases B of the source and destination RDS instances and execute the required statement based on the database engine of the source and destination RDS instances to view the session information. Make sure that write operations are being performed in a new session.

    MySQL

    show processlist;

    SQL Server

    select * from sys.dm_exec_connections;

    Oracle

    select sid,serial#,username,program,machine,status from v$session;

    PostgreSQL

    select * from pg_stat_activity;

    Redis

    CLIENT LIST

    MongoDB

    use admin
    db.runCommand({currentOp: 1, $all:[{"active" : true}]})
    Note

    After you execute the required statement, the information that is returned includes the processes or sessions for Data Transmission Service (DTS) to connect to Databases B of the source and destination RDS instances.

  7. Write the application data to Databases B of the source and destination RDS instances. Make sure that the source and destination RDS instances run as expected or for seven days.

  8. After you test all features that are related to your service and make sure that no issues are detected, shut down Database B of the source RDS instance.

Simple splitting solution

Note

If you use the simple splitting solution, you do not need to modify your application. However, a rollback failure may occur.

  1. Configure a data migration task for the source and destination RDS instances. Select Database B as the object to be migrated. For more information, see Overview of data migration scenarios.

  2. Wait until the task progress bar shows "Incremental Data Migration" and "The migration task is not delayed" or a delay time of less than 5 seconds.

    Data migration task 1 (Forward)
    Note

    If you do not select Incremental Data Migration when you configure the data migration task, the task progress bar does not show "Incremental Data Migration". After the data migration is complete, the migration task automatically stops. We recommend that you suspend you service and stop writing data to the source database before you run the data migration task. In this case, go to Step 6.

  3. Check whether the data in Databases B of the source and destination RDS instances is consistent.

  4. If the data is consistent, stop the data migration task. For more information, see Stop a data migration task.

    Warning

    The database accounts that are used for data migration are granted the read and write permissions. After the data migration task is complete, you must delete the accounts or revoke the write permissions of the accounts to ensure data security.

  5. Disconnect the application from Database B of the source RDS instance.

    Note

    After the application is disconnected from Database B of the source RDS instance, if the services and features that are related to Database A of the source RDS instance are affected, you must disconnect the application from the source RDS instance.

  6. Log on to Database B of the source RDS instance and execute the required statement based on the database engine of the source RDS instance to view the session information. Make sure that write operations are being performed in a new session.

    MySQL

    show processlist;

    SQL Server

    select * from sys.dm_exec_connections;

    Oracle

    select sid,serial#,username,program,machine,status from v$session;

    PostgreSQL

    select * from pg_stat_activity;

    Redis

    CLIENT LIST

    MongoDB

    use admin
    db.runCommand({currentOp: 1, $all:[{"active" : true}]})
    Note

    After you execute the required statement, the information that is returned includes the processes or sessions for DTS to connect to Database B of the source RDS instance.

  7. Create and start a data migration task that can be executed to migrate incremental data generated in Database B of the destination RDS instance to Database B of the source RDS instance.

    The migration task that is created in this step is used for data rollback. After your service is resumed, if an error occurs, you can switch workloads to the source database.

    Warning

    When you configure the preceding data migration task, you can select only "Incremental Data Migration" in the "Configure Migration Types and Objects" step. Then, you can select the database or table that you want to migrate back to the source database.

  8. Make sure that your application is disconnected from Database B of the source RDS instance. Verify that data is consistent between Databases B of the source and destination RDS instances. Then, switch the workloads on your application to Database B of the destination RDS instance and resume your service.

  9. Log on to Database B of the destination RDS instance and execute the required statement based on the database engine of the destination RDS instance to view the session information. Make sure that write operations are being performed in a new session.

    MySQL

    show processlist;

    SQL Server

    select * from sys.dm_exec_connections;

    Oracle

    select sid,serial#,username,program,machine,status from v$session;

    PostgreSQL

    select * from pg_stat_activity;

    Redis

    CLIENT LIST

    MongoDB

    use admin
    db.runCommand({currentOp: 1, $all:[{"active" : true}]})
    Note

    After you execute the required statement, the information that is returned includes the processes or sessions for DTS to connect to Database B of the source RDS instance.

  10. After you switch workloads to the destination database, make sure that the destination RDS instance runs as expected or for seven days.

  11. After you test all features that are related to your service and make sure that no issues are detected, shut down Database B of the source RDS instance and stop the data migration task. For more information, see Stop a data migration task.

    Warning

    The database accounts that are used for data migration are granted the read and write permissions. After the data migration task is complete, you must delete the accounts or revoke the write permissions of the accounts to ensure data security.