How NetEase Hive RDS Enables Fast, Reliable MySQL Instance Migration

1. Introduction

Instance migration refers to moving part or all of a database schema and data from a source instance to a target instance. The source is the exporting instance, the target is the importing instance. Migrations can be homogeneous (e.g., MySQL‑to‑MySQL) or heterogeneous (e.g., Oracle‑to‑MySQL).

2. Use Cases

Self‑built to RDS : Many legacy MySQL instances run on physical servers; migrating them to RDS provides better fault handling, online scaling, and upgrades.

Other cloud to RDS : A significant portion of users move MySQL instances from other public clouds to Hive RDS; statistics show about 50% of migrations target external cloud instances.

3. Technical Challenges

How to quickly create a consistent backup of the source instance?

How to minimize impact on the source instance’s business workload during backup?

How to import the backup into the target instance efficiently?

How to synchronize incremental changes from source to target?

How to ensure the whole migration completes efficiently?

4. Solution Overview

4.1 Multi‑Threaded Logical Backup

The team selected mydumper for logical backup because it supports multi‑threaded, record‑level concurrency, which outperforms physical tools like xtrabackup (cannot run remotely) and other logical tools such as mysqldump and mysqlpump (single‑threaded or table‑level concurrency).

Benchmark comparison of backup tools:

mydumper’s record‑level multi‑threading allows each worker thread to read a snapshot while the main thread holds a brief global read lock, ensuring consistency without long‑lasting locks.

Backup workflow:

4.2 Business Load Monitoring & Adjustment

During backup, the system monitors MySQL load and can automatically adjust the number of export threads. Users may set a maximum lock‑hold time; if exceeded, the lock is released and the migration fails, allowing a retry during a low‑traffic window.

Load‑aware throttling diagram:

When load exceeds a configured threshold, migration pauses; once load drops, it resumes, optionally scaling the export thread count dynamically.

InnoDB buffer‑pool (BP) tuning is also applied when the migration account has sufficient privileges, reducing BP pollution from migration queries.

4.3 Multi‑Threaded Data Import

Data is imported using myloader, the counterpart of mydumper. The target instance, being idle, can run with a high degree of parallelism. During import, slow‑log and binary‑log are disabled and innodb_flush_log_at_trx_commit is set to 0 to maximize throughput, then restored after completion.

4.4 Parallel Filtered Replication for Incremental Sync

For incremental migration, MySQL replication is used. The system selects target RDS versions based on the source version: InnoSQL 5.5.30 for MySQL 5.5 or lower, and InnoSQL 5.7.12 for MySQL 5.6/5.7, to leverage GTID‑based replication and the CHANGE REPLICATION FILTER syntax for online filtering without restart.

Parallel replication techniques are applied to reduce lag, especially when migrating from MySQL 5.6 (GTID not fully mature) to MySQL 5.7.

5. Ensuring Efficient Migration

5.1 Migration Evaluation & Preparation

Select a low‑traffic window for migration.

Ensure business connections can switch to the target instance in one step.

Allocate sufficient storage on the target.

Create migration‑specific database accounts with required privileges.

5.2 Pre‑Check

The pre‑check validates migration account permissions (SELECT, LOCK TABLE, REPLICATION SLAVE/CLIENT) and required MySQL parameters (e.g., server_id, log_bin) for incremental sync. Errors are reported with actionable hints.

5.3 Error Retry & Progress Display

Migration progress is shown with percentage bars for each stage. If an error occurs (e.g., lock timeout due to large MyISAM tables), the system reports the cause, allows parameter adjustments, and retries without restarting the whole migration.

5.4 Completing Migration

After confirming no replication lag, the migration ends and the business IP is switched to the target instance. Users must ensure the necessary database accounts exist on the target before the switch.

6. References

http://www.innoMySQL.com/article/25383.html

http://MySQLserverteam.com/introducing-MySQLpump/

http://www.innoMySQL.com/article/25456.html

http://dev.MySQL.com/doc/refman/5.7/en/innodb-performance-midpoint_insertion.html

http://dev.MySQL.com/doc/refman/5.7/en/replication.html