ApsaraDB RDS:[Deprecated] Convert TokuDB to InnoDB

Background

Percona stopped maintaining TokuDB, leaving known bugs unfixed and causing business loss in extreme cases. As a result, ApsaraDB RDS for MySQL dropped TokuDB support on August 1, 2019.

• Effective date: August 1, 2019

• Affected scope: RDS instances using the TokuDB storage engine

Check if your instance is affected

Run the following SQL statements in Data Management (DMS) to identify TokuDB tables:

-- View the default storage engine of your RDS instance
SHOW ENGINES;

-- View the storage engine of a specific table
SHOW CREATE TABLE <table_name>;

Potential impacts

Before migrating, review the following impacts:

• CPU and IOPS: After migration, CPU utilization decreases but IOPS increases when reading the same volume of data, because InnoDB does not compress data pages.

• Endpoint switch: Full migration switches the connection endpoint. Schedule migrations during off-peak hours.

• Engine version change: If you change the database engine version during migration, test compatibility in advance.

Choose a solution

Select a solution based on your table size and tolerance for downtime:

After completing any solution, change the default_storage_engine parameter value to InnoDB. If you skip this step, new tables created without an explicit ENGINE clause will still attempt to use TokuDB — which is no longer supported and causes errors. See After the migration.

Solution 1: ALTER TABLE (direct)

This solution directly alters the storage engine with a single SQL statement. DML operations are blocked during the operation, so it is only suitable for small tables where brief blocking is acceptable.

1. Log on to your RDS instance using .

2. In the top navigation bar, choose SQL Operations > SQL Window.

3. Run the following statement:

   ALTER TABLE test.testfs ENGINE = InnoDB;

   

Solution 2: gh-ost (online migration)

This solution uses gh-ost, an open-source online DDL tool developed by GitHub. It copies data to a ghost table in the background and cuts over during off-peak hours, keeping DML operations unblocked.

How it works

gh-ost creates a temporary ghost table with the same schema as the original, copies data incrementally, then reads binary logs through a simulated replica to replay ongoing changes. When you're ready, it renames the tables to complete the cutover. I/O spikes during the initial full copy, but the --chunk-size parameter lets you limit the throughput.

• Advantage: Lets you specify the exact cutover time and pause or cancel at any point.

• Limitation: Each table requires a separate command, which becomes tedious for large numbers of tables. Use Solution 3 instead.

Solution 3: DTS table-level sync

This solution uses Data Transmission Service (DTS) to sync data from the original TokuDB table to a new InnoDB table in real time, then renames the tables during off-peak hours. It handles many tables simultaneously, making it well-suited for batch migration.

DTS data synchronization instances are billed separately. For pricing details, see Data Transmission Service pricing.

1. Log on to your RDS instance using .

2. In the top navigation bar, choose SQL Operations > SQL Window.

3. Create a temporary InnoDB table with the same schema as your TokuDB table. For example:

   CREATE TABLE `testfs_tmp` (
     `id` int(11) NOT NULL AUTO_INCREMENT,
     `vc` varchar(8000) DEFAULT NULL,
     PRIMARY KEY (`id`)
   ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

4. Purchase a DTS instance.

5. In the DTS console left-side navigation pane, click Data Synchronization.

6. Find the purchased instance and click Configure Synchronization Channel in the Actions column.

7. Configure the source and destination instance details:

   SSL encryption significantly increases CPU utilization. For setup instructions, see Configure SSL encryption for an RDS instance.

   Section	Parameter	Value
   Source instance details	Instance type	RDS Instance
   	Instance ID	Select the RDS instance to migrate
   	Encryption	Non-encrypted or SSL-encrypted
   Destination instance details	Instance type	RDS Instance
   	Instance ID	Select the same RDS instance
   	Encryption	Non-encrypted or SSL-encrypted

   

8. Click Set Whitelist and Next.

9. Wait for the synchronization accounts to be created, then click Next.

10. Move the testfs table to the selected tables section and click Edit.

    

11. Set the destination table name to testfs_tmp and click OK.

    

12. Click Next.

13. Select Initial Full Data Synchronization and click Precheck.

    

14. Wait for the precheck to complete, then click Close.

15. Wait until the Delay value drops to 0 Milliseconds, which means the two tables are fully in sync.

    

16. In the DMS SQL Window, rename the tables to complete the cutover:

    DTS reports a synchronization error after the rename — this is expected and can be ignored.

     RENAME TABLE `testfs` TO `testfs_del`, `testfs_tmp` TO `testfs`;

17. Verify the data. Once confirmed, release the DTS instance to stop billing and delete the testfs_del table.

Solution 4: DTS instance migration

This solution migrates an entire RDS instance to a new instance using DTS. It is best suited when you need to upgrade the instance or can tolerate a moderate service interruption for the endpoint switch.

1. Export all schema scripts from the source instance. In each script, replace ENGINE=TokuDB with ENGINE=InnoDB. For example: Change:

   CREATE TABLE t1 (id INT, name VARCHAR(10)) ENGINE=TokuDB;

   To:

   CREATE TABLE t1 (id INT, name VARCHAR(10)) ENGINE=InnoDB;

2. Create a new RDS instance and use the modified scripts to create the databases and tables. For details, see Create an ApsaraDB RDS for MySQL instance.

3. Use DTS to migrate data from the source instance to the new instance. For details, see Configure one-way data synchronization between ApsaraDB RDS for MySQL instances.

   When configuring the DTS task, select only Initial Full Data Synchronization.

   

4. Once the synchronization delay reaches 0, update your application connection string to point to the new instance endpoint.

After the migration

After completing any of the solutions above, update the default_storage_engine parameter on your RDS instance to InnoDB.

To update the parameter, go to the RDS console, navigate to Parameters, and set default_storage_engine to InnoDB.