MySQL不停服迁移实战：双写架构与Flink-CDC技术选型指南

1. 企业级数据库迁移的核心挑战与解决方案

在数字化业务持续运行的背景下，数据库迁移如同给飞行中的飞机更换引擎。某电商平台在2024年大促期间进行MySQL迁移时，因未处理好数据一致性导致3000万订单状态异常，直接损失超亿元。这个典型案例揭示了三个关键挑战：

数据一致性保障需要解决：

• 在线业务持续写入带来的动态数据同步
• 网络延迟或故障导致的增量数据丢失风险
• 异构数据库间字段类型、字符集等差异

业务连续性要求体现在：

• 7×24小时服务不可中断的SLA承诺
• 迁移期间性能波动需控制在10%以内
• 新旧系统并行时的资源消耗平衡

技术方案选型的典型对比：

方案类型	适用场景	数据延迟	业务侵入性	复杂度
主从同步	同构数据库小版本升级	秒级	低	★★☆
双写架构	异构迁移/架构改造	毫秒级	高	★★★
Flink-CDC	实时数据管道建设	亚秒级	中	★★☆
触发器同步	少量表同步	秒级	高	★★★

实际项目中，双写+Flink-CDC混合方案已成为头部互联网企业的首选。某社交平台采用该方案在3个月内完成200TB用户数据迁移，期间峰值QPS达50万，业务端无感知。

2. 双写架构实施详解与避坑指南

2.1 环境准备阶段关键配置

MySQL主从同步的基础配置需要特别注意以下参数：

# my.cnf 主库配置
server-id = 1
log_bin = /var/lib/mysql/mysql-bin
binlog_format = ROW
binlog_row_image = FULL
sync_binlog = 1
gtid_mode = ON
enforce_gtid_consistency = ON

# 从库额外配置
read_only = ON
skip_slave_start = OFF

常见踩坑点：

• 未启用GTID导致主从切换后数据不一致
• binlog_row_image未设置FULL导致更新操作丢失字段
• sync_binlog=0时主机宕机可能丢失事务

提示：生产环境建议设置expire_logs_days=7，避免binlog过早清除影响同步

2.2 双写开关的优雅实现

在Spring Boot中可通过自定义注解实现动态路由：

@Target({ElementType.METHOD, ElementType.TYPE})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface DualWrite {
    String value() default "master";
}

// AOP切面实现
@Around("@annotation(dualWrite)")
public Object dualWriteAround(ProceedingJoinPoint joinPoint, DualWrite dualWrite) {
    String dsKey = dualWriteSwitch.isActive() ? 
                  "dualMaster" : dualWrite.value();
    DynamicDataSourceContextHolder.setDataSourceKey(dsKey);
    try {
        return joinPoint.proceed();
    } finally {
        DynamicDataSourceContextHolder.clear();
    }
}

灰度发布策略建议采用用户ID哈希分片：

def should_write_new(user_id):
    # 首批开放5%流量
    return hash(user_id) % 100 < 5 

2.3 数据一致性校验方案

全量校验脚本示例（使用pt-table-checksum）：

pt-table-checksum \
  --replicate=test.checksums \
  --databases=orders \
  --tables=order_{0..19} \
  h=old_master,u=check_user,p=password

增量校验方案对比：

方法	精度	性能影响	实现复杂度
触发器记录变更	100%	高	★★★
定时扫描时间戳	95%	中	★★☆
消息队列异步比对	99.9%	低	★★★

某金融项目采用CRC32校验码比对方案，在10亿级数据量下校验耗时从8小时降至15分钟：

-- 新旧库同时执行
SELECT 
    table_name,
    COUNT(*) AS row_count,
    BIT_XOR(CAST(CRC32(CONCAT_WS(',',*)) AS UNSIGNED)) AS crc_hash
FROM orders
GROUP BY table_name;

3. Flink-CDC技术深度解析

3.1 核心原理与性能优化

Flink-CDC的增量快照算法工作流程：

1. 获取全局锁记录binlog位置
2. 释放锁并行扫描全表数据
3. 合并全量数据与增量变更
4. 持续监听binlog事件

关键配置参数：

MySqlSource<String> source = MySqlSource.<String>builder()
    .hostname("mysql-host")
    .port(3306)
    .scanNewlyAddedTableEnabled(true)  // 自动捕获新表
    .databaseList("inventory")
    .tableList("inventory.products")
    .username("flinkuser")
    .password("flinkpw")
    .serverId("5400-5408")  // 集群内唯一
    .deserializer(new JsonDebeziumDeserializationSchema())
    .snapshotMode(SnapshotMode.INITIAL)  // 全量+增量
    .parallelism(4)  // 根据表数量调整
    .splitSizeMB(128)  // 大表分片
    .fetchSize(1024)
    .build();

性能调优经验：

• 10万QPS场景下建议设置chunkKeyColumn为自增主键
• 网络抖动时调整connectTimeout=60s和connectionPoolSize=15
• 大事务处理需配置transactionSize=10000

3.2 与双写方案的对比分析

某物流平台实测数据：

指标	双写方案	Flink-CDC
同步延迟	50-100ms	200-500ms
CPU消耗	15%-20%	8%-12%
数据一致性	最终一致	精确一次
最大吞吐量	5万TPS	20万TPS
故障恢复时间	手动干预	自动恢复

混合架构实践：

graph TD
    A[业务应用] -->|双写| B(旧MySQL)
    A -->|双写| C(新MySQL)
    B -->|Flink-CDC| C
    C --> D[数据校验服务]
    D --> E[报警系统]

4. 生产环境落地 checklist

4.1 迁移前验证清单

1. [ ] 网络带宽测试（至少1Gbps专线）
2. [ ] 磁盘IOPS性能基准测试
3. [ ] 回滚方案全链路演练
4. [ ] 监控指标阈值设置：
   • 主从延迟 < 1s
   • 线程池使用率 < 80%
   • 磁盘空间预警 > 30%

4.2 割接当天的SOP

T-1小时：

• 确认备份有效性（执行SHOW SLAVE STATUS）
• 暂停定时任务和批量作业
• 业务方确认无重大活动

T-0时刻：

# 分批次切流脚本
for i in {1..10}; do
  curl -X POST "http://router-api/switch?percent=${i}0"
  sleep 300  # 每批观察5分钟
done

T+1小时：

• 校验核心表数据一致性
• 监控新集群性能指标
• 逐步下线旧库写权限

5. 典型故障处理实录

案例1：主键冲突导致同步中断 现象：Flink作业报Duplicate entry '12345' for key 'PRIMARY' 根因：目标表存在自增主键而源表为UUID 解决方案：

-- 目标表修改主键类型
ALTER TABLE orders MODIFY COLUMN id VARCHAR(36);

案例2：大字段同步性能瓶颈 优化前：text字段导致单条记录传输耗时50ms 优化后：通过excludeColumns过滤非必要字段

.excludeColumns(".*\\.description,.*\\.attachment")

案例3：时区不一致导致时间错误 配置方案：

debezium:
  database:
    serverTimezone: Asia/Shanghai
    connectTimeZone: Asia/Shanghai

在实施过程中发现，某次迁移因未设置serverTimezone导致订单时间偏差8小时，引发后续对账异常。这提醒我们必须在测试阶段验证所有时间敏感字段。