Performance Evaluation and Optimization of MySQL Migration to Tencent Cloud CDB

1. Background After a severe outage and data recovery incident, Weimeng's DBA team decided to migrate their core MySQL databases to Tencent Cloud CDB (TencentDB for MySQL) to improve availability, security, and performance, abandoning self‑built database services.

2. Product Selection The chosen configuration was a Shanghai‑region CDB instance with 16 CPU cores and 64 GB memory. Benchmark tables were built from production data, and both baseline and business load tests were conducted across various concurrency levels (16, 32, 64, 100, 200, 400).

3. Solution Verification

3.1 Stress Test Method The MySQL official tool mysqlslap was used, e.g., mysqlslap --iterations=100 --create-schema='test' --query="query.sql" --number-of-queries=20000 --delimiter=";" --concurrency=100 which runs 20 000 queries per iteration at the specified concurrency.

3.2 Issues Encountered

NUMA binding problem CDB used cgroup‑based CPU isolation while the self‑built environment used core binding, causing cross‑NUMA memory accesses and a 4‑fold performance drop. Aligning CDB’s CPU isolation with the self‑built setup restored performance.

Network parameter problem High concurrency caused many short‑lived connections; tuning TCP parameters (tcp_rmem, tcp_wmem, tcp_max_syn_backlog, somaxconn) eliminated the degradation.

Low‑concurrency performance issue An extra TGW (gateway) in the CDB network added latency; removing TGW reduced the delay and matched self‑built performance.

Range‑query performance regression A bug in CDB 5.6’s handling of read‑only transaction IDs caused inefficient innodb_rows_read counting; fixing the bug in a newer version yielded better performance than the self‑built system.

Overall QPS slightly lower at 100 concurrency Parameter mismatches (innodb_io_capacity_max, table_open_cache, etc.) were tuned, leading to noticeable QPS improvements.

3.3 Optimization Measures The team applied CPU quota adjustments, NUMA‑aware core binding, network stack tuning, and upgraded CDB to a version with the range‑query bug fixed. Tools such as sysbench , custom Lua scripts, perf , and pt‑pmp were used for profiling.

4. Migration Process

Configured CDB instances based on historical QPS and business criticality.

Created DTS migration tasks, performed data consistency checks (row counts, checksum).

Switched DNS, stopped DTS, killed old DB connections, and verified connectivity.

Conducted post‑migration testing and performance verification.

5. Final Results

5.1 Performance Data Under 100‑concurrency load, most instances showed QPS variations within 25 %. Baseline tests indicated CDB QPS improvements of 4‑10× and business‑load SQL improvements of over 2× compared to the original environment.

5.2 Overall Gains The migration delivered significant performance gains, higher stability, and satisfied business requirements.

6. Post‑Migration Recommendations

Assess QPS requirements before selecting CDB specifications.

Conduct thorough benchmark comparisons between CDB and existing databases.

Align CDB version and MySQL parameters with the source system.

Automate migration steps to reduce downtime.

Run ANALYZE TABLE after DTS to refresh statistics.

Continuously monitor logs for early issue detection.

7. Acknowledgements Thanks to the Tencent CDB/CynosDB R&D team and internal product architecture team for their rapid support, and to the Weimeng team for providing the platform and collaboration.