
Learn how to migrate from MySQL to TiDB with minimal downtime. Covers schema conversion, data migration, cutover strategies, and post-migration validation.
Migrating from MySQL to TiDB enables horizontal scalability, strong consistency, and cloud-native operations. This guide provides a comprehensive, practical approach for DBAs to migrate production workloads from MySQL to TiDB with minimal downtime.
Table of Contents
Why Migrate to TiDB?
- Horizontal Scalability: Scale out by adding nodes
- MySQL Compatibility: Supports most MySQL syntax and tools
- Cloud-Native: Built for Kubernetes and hybrid cloud
- HTAP: Hybrid transactional/analytical processing
- Strong Consistency: Distributed transactions with Raft
| Feature | MySQL | TiDB |
|---|---|---|
| Horizontal Scaling | Limited | Excellent |
| Distributed SQL | No | Yes |
| Online Schema Change | Limited | Yes |
| Cloud-Native | No | Yes |
| HTAP | No | Yes |
Pre-Migration Assessment
- Inventory: List all databases, tables, and critical applications
- Compatibility Check: Use TiDB Compatibility Checker
- Performance Baseline: Capture current QPS, latency, and slow queries
- Data Volume: Estimate total data size and growth rate
- Downtime Window: Plan for cutover and rollback
-- Check MySQL version and features
SELECT VERSION();
SHOW ENGINES;
SHOW VARIABLES LIKE 'sql_mode';Schema Conversion
1. Export MySQL Schema
mysqldump -h <mysql_host> -u <user> -p --no-data --routines --triggers --events mydb > mydb_schema.sql2. Review and Adjust Schema
- Remove unsupported features (e.g., spatial indexes, FULLTEXT on non-TiDB tables)
- Convert
ENUM/SETtypes toVARCHARif needed - Replace
UNSIGNEDwith signed types (TiDB does not support unsigned) - Remove
ZEROFILL,AUTO_INCREMENTis supported - Check for partitioned tables (TiDB supports RANGE/HASH)
-- Example: Convert ENUM to VARCHAR
ALTER TABLE users MODIFY status VARCHAR(20);
-- Remove unsupported index types
DROP INDEX idx_fulltext ON articles;3. Import Schema to TiDB
mysql -h <tidb_host> -P 4000 -u <user> -p mydb < mydb_schema.sqlData Migration
1. Full Data Migration with TiDB Data Migration (DM)
- TiDB Data Migration (DM) supports full and incremental sync
- Deploy DM-master and DM-worker nodes
# Example DM task configuration
name: mydb-migration
mode: all
shard-mode: "pessimistic"
mysql-instances:
- source-id: "mysql-replica-01"
meta:
binlog-name: "mysql-bin.000001"
binlog-pos: 4
target-database:
host: "tidb-host"
port: 4000
user: "tidb_user"
password: "tidb_pass"
black-white-list:
bw-list:
do-dbs: ["mydb"]
# Save as mydb-task.yaml# Start DM task
./dmctl --master-addr=127.0.0.1:8261 start-task mydb-task.yaml2. Alternative: Lightning for Large Datasets
- TiDB Lightning for fast import of large data
# Export MySQL data as CSV or SQL
mysqldump -h <mysql_host> -u <user> -p --single-transaction --quick --no-create-info mydb > mydb_data.sql
# Configure Lightning and import
lightning -config tidb-lightning.tomlIncremental Sync and Cutover
- DM supports real-time binlog replication (incremental sync)
- Monitor lag with
query-statusin dmctl - Schedule cutover during low-traffic window
- Stop writes to MySQL, wait for DM to catch up
- Point applications to TiDB
# Check DM sync status
./dmctl --master-addr=127.0.0.1:8261 query-status
# Stop MySQL writes (read-only mode)
SET GLOBAL read_only = ON;
# Wait for lag to reach 0, then cutoverPost-Migration Validation
- Data Consistency: Use sync-diff-inspector
- Application Testing: Run integration and performance tests
- Query Plan Review: Use
EXPLAINto compare plans - Monitor Metrics: QPS, latency, error rates
# Run sync-diff-inspector
sync-diff-inspector --config diff-config.tomlCommon Issues and Solutions
| Issue | Solution |
|---|---|
| Unsupported SQL syntax | Refactor queries, check compatibility docs |
| Data type mismatch | Adjust schema, use compatible types |
| Partitioning differences | Use supported partition types in TiDB |
| Performance regression | Tune TiDB config, review indexes, analyze SQL |
| Application connection error | Update drivers, use port 4000 for TiDB |
Best Practices
- Test migration in staging with production-like data
- Use DM for minimal downtime and incremental sync
- Monitor both source and target during migration
- Document all schema changes and migration steps
- Plan rollback strategy in case of issues
- Engage with PingCAP support for complex migrations
Conclusion
Migrating from MySQL to TiDB unlocks scalability and cloud-native features for modern workloads. With careful planning, the right tools, and thorough validation, you can achieve a seamless migration with minimal risk.
For expert assistance with MySQL to TiDB migrations, our team provides database migration consulting and cloud-native database solutions.
Need help migrating from MySQL to TiDB? Our certified DBAs can help you plan and execute a seamless migration. Contact us for a free consultation.
Written by
Abhishek
KEEP LEARNING WITH THEDBADMIN
Turn this guide into a skill you can prove
Keep reading
Related articles
NextGen DBA + AI Engineer Bootcamp
Instructor-led, lab-first training for production DBAs: PostgreSQL, MongoDB, Docker, Kubernetes and AI.
- Live labs on real execution plans
- Backup, PITR & HA in production
- pgvector, RAG & AI for DBAs
🛒 FROM THE SHOP

PostgreSQL Observability Pipeline with Prometheus, Grafana, and Alloy
PDF · 10 pages
Free