TiDB 和 MySQL 的迁移过程是什么？会遇到什么问题？怎么解决的？
Git高速下载
程序员面试资料大全｜各种技术书籍等资料-1000G
一、迁移方案全景图
二、迁移全流程详解
1. 评估与设计阶段
| 步骤 | 关键任务 | 工具/方法 |
|---|---|---|
| 兼容性评估 | 检查 SQL 语法、数据类型、事务隔离级别、自增 ID 等兼容性 | PingCAP TiDB DM 的 checker 组件 |
| 架构设计 | 设计 TiDB 集群拓扑（PD/TiKV/TiDB 节点配比）、存储规划（SSD/NVMe） | TiUP 部署工具 + 资源计算器 |
| 业务切割 | 按业务模块分批次迁移（优先非核心模块） | 业务流量分析（如 Prometheus 监控） |
2. 数据同步阶段
核心工具：TiDB Data Migration (DM)
架构：
操作流程：
- 全量迁移（Dumpling + Loader）：
# 导出 MySQL 全量数据 dumpling -h 127.0.0.1 -P 3306 -u root -p xxx -o /data/dump# 导入 TiDB tiup tidb-lightning -config lightning.toml - 增量同步（DM Binlog Replication）：
# dm-task.yaml name: test-task task-mode: incremental target-database:host: "tidb-cluster"user: "root"password: "***" mysql-instances:- source-id: "mysql-replica-01"loader-config-name: "global"syncer-config-name: "global"
3. 流量切换阶段
| 策略 | 适用场景 | 操作要点 |
|---|---|---|
| 业务双写 | 容忍短暂不一致的读业务 | 应用层同时写入 MySQL 和 TiDB，通过日志对比校验 |
| DNS 切换 | 简单业务 | 修改域名解析指向 TiDB，TTL 需调低至 60s 内 |
| Proxy 层切换 | 高可用架构（如 ShardingSphere） | 通过配置中心动态切流，支持灰度发布 |
| TiDB 读分流 | 降低迁移风险 | 写流量仍在 MySQL，读流量切至 TiDB（需解决主从延迟问题） |
三、典型问题与解决方案
1. 数据兼容性问题
| 问题现象 | 根因分析 | 解决方案 |
|---|---|---|
| 自增主键冲突 | TiDB 分布式自增 ID 实现差异 | 改用 AUTO_RANDOM 或 SHARD_ROW_ID_BITS 分散写入热点 |
| SQL 语法不兼容 | 如 SELECT ... LOCK IN SHARE MODE | 业务改造：替换为 SELECT ... FOR UPDATE 或开启 TiDB 悲观事务 |
| timestamp 默认值错误 | MySQL 允许 0000-00-00 00:00:00 | 迁移前清理非法数据 或 设置 TiDB 的 sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES' |
2. 性能问题
| 问题现象 | 根因分析 | 解决方案 |
|---|---|---|
| 写入热点 | 单表自增 ID 导致 Region 热点 | 提前做表分区（SHARD_ROW_ID_BITS=4） 或 改用 UUID 等分布式 ID |
| DDL 执行卡顿 | 大表加列/索引阻塞复制 | 使用 Online DDL 工具（如 gh-ost） 或 TiDB 的 ALGORITHM=INPLACE |
| TiCDC 同步延迟 | 大事务（>5GB）阻塞复制 | 拆分事务：innodb_flush_log_at_trx_commit=2 + 减小批量操作尺寸 |
3. 运维问题
| 问题现象 | 根因分析 | 解决方案 |
|---|---|---|
| GTID 同步中断 | MySQL 主从切换导致 GTID 跳跃 | DM 开启 enable-gtid + 配置 relay_log_purge=0 保留 Relay Log |
| 字符集乱码 | TiDB 默认字符集为 utf8mb4 | 导出时指定字符集：dumpling --charset=utf8 |
| 外键约束失败 | TiDB 外键仅语法兼容（实际不生效） | 业务层移除外键，改由应用逻辑保证 |
四、关键优化策略
1. 迁移加速方案
- 物理导入优化：
# lightning.toml [tikv-importer] backend = "local" # 比 "log" 模式快 5 倍以上 sorted-kv-dir = "/nvme_dir" # 使用 NVMe 磁盘 - 并行复制：
# dm-task.yaml syncer-config:worker-count: 16 # 根据 CPU 核数调整batch: 2000 # 增大批量提交
2. 数据一致性校验
工具：TiDB Data Check (Sync-diff-inspector)
./sync_diff_inspector \--config=diff-config.toml \--table=test.t1 \ # 指定校验表--range="id > 1000 and id < 2000" # 分段校验
校验结果处理：
- 自动修复：
--fix-sql-file=fix.sql - 忽略无关差异（如
AUTO_INCREMENT值）
3. 回滚预案
五、迁移后监控要点
| 监控项 | 工具 | 告警阈值 |
|---|---|---|
| 复制延迟 | DM Metrics + Grafana | > 30s 持续 5min |
| TiDB 响应时间 | Prometheus + Alertmanager | P99 > 1s |
| Region 均衡 | TiDB Dashboard | Store 间 Region 数差异 > 20% |
| 大查询 | TiDB Slow Query Log | 执行时间 > 10s |
六、实战经验总结
-
避坑指南：
- 提前测试 事务隔离级别：TiDB 默认 SI（快照隔离） vs MySQL RR（可重复读）
- 禁用 外键/存储过程：TiDB 兼容度有限
- 处理 大字段：LOB 类型数据需调大
txn-entry-size-limit
-
性能压测必做项：
# 使用 Sysbench 验证 TPS/QPS sysbench oltp_read_write --tables=32 --table-size=1000000 run# 对比迁移前后指标 MySQL QPS: 15k → TiDB QPS: 38k (横向扩展后) -
成本优化：
- 用 TiFlash 替代 ES 做实时分析，减少技术栈复杂度
- 冷热数据分离：将历史数据归档至 S3（通过 TiDB 外部表访问）
程序员面试资料大全｜各种技术书籍等资料-1000G
Git高速下载
