大规模数据库迁移中的 CDC 吞吐优化实践
内容提要
本文介绍基于Amazon MSK Connect与Debezium的高吞吐CDC同步方案，解决AWS DMS单任务无法追平高写入量MySQL源库延迟的问题。通过单连接读取binlog、多Task并行写入Aurora MySQL，实现N倍吞吐提升，且不增加源库压力。文章涵盖架构设计、部署步骤、并行度调优及常见问题，适用于自建MySQL迁移AWS场景。
延伸解读
读写解耦是核心设计
方案的关键在于将“读”与“写”分离：源端仅用一条binlog连接读取所有变更，目标端则通过多个Task并行写入。这种设计避免了DMS多任务拆分时源库连接数随任务数线性增长的问题，使得并行度提升不再以增加源库压力为代价。对于高写入量源库，这是能否在不影响业务的前提下追平延迟的关键。
并行度调优需结合表规模
文章给出了不同表数量下的推荐配置：2-10张表时单Sink且tasks.max设为2~4；10-50张表时按业务域拆分多个Sink；50张以上则需确保Topic分区数不小于Task数。这提示读者，并行度并非越大越好，需根据表数量和数据量合理规划，避免资源浪费或配置不当导致性能瓶颈。
常见问题多与配置细节相关
文章列举的五个常见问题均源于配置细节：时间格式转换、消息格式一致性、插件依赖缺失、插件更新机制、Topic自动创建。这些问题在部署时容易忽略，但会导致同步失败或数据错误。建议读者在实施前仔细核对各项配置，尤其是SMT转换和插件打包，以减少排障时间。
Q&A
AWS DMS 单任务在 CDC 同步中无法追平延迟时，有什么替代方案？
可以使用基于 Amazon MSK Connect 和 Debezium 的高吞吐 CDC 同步方案，通过单连接读取 binlog，多 Task 并行写入目标库，线性提升同步吞吐量，解决 DMS 单任务追平延迟的问题。
为什么 DMS 多任务并行会增加源库压力？
因为每个 DMS 任务都会建立一条到源库的 binlog 连接，任务越多，源库需要服务的 binlog dump 连接就越多，导致源库 I/O 和 CPU 压力线性增长，可能影响线上业务。
Debezium + MSK Connect 方案如何实现读写解耦？
Debezium Source Connector 通过单个数据库连接读取全部 binlog 事件，按表分发到 Kafka Topic；JDBC Sink Connector 配置多个 Task 并行消费并写入目标库，实现 1 次 binlog 读取、N 倍并行写入，不增加源库压力。
部署 Debezium + MSK Connect 方案需要哪些前置条件？
需要 Amazon MSK 集群（建议 Provisioned 模式，kafka.m5.large，3 个 Broker），开启 auto.create.topics.enable=true；源端 MySQL 开启 binlog（binlog_format=ROW）；目标端 Aurora MySQL 已建好表结构；IAM 角色信任 kafkaconnect.amazonaws.com；S3 存储桶存放插件；确保源库与 MSK 网络连通。
如何配置 Debezium Source Connector 和 JDBC Sink Connector？
Source Connector 配置 topic.prefix=cdc、snapshot.mode=schema_only、schemas.enable=true、tasks.max=1；Sink Connector 配置 topics.regex=cdc\.mydb\..*、insert.mode=upsert、delete.enabled=true、tasks.max=N，并添加 unwrap、routeTopic、convertTimestamp 等 SMT。注意先启动 Source Connector 创建 Topic 后再创建 Sink Connector。
如何根据表数量调整 JDBC Sink 的并行度？
2-10 张表：单个 Sink，tasks.max=2~4；10-50 张表：按业务域拆分 2-3 个 Sink，每个 tasks.max=4~8；50+ 张表：多个 Sink，并确保 Topic partition 数 ≥ task 数。
Debezium 时间格式与 MySQL 不兼容怎么办？
使用 TimestampConverter SMT 将 Debezium 输出的 ISO 8601 格式时间转换为 MySQL 兼容的 yyyy-MM-dd HH:mm:ss 格式。
MSK Connect 更新插件不生效如何解决？
MSK Connect 的 Custom Plugin 是不可变的，更新 S3 上的 zip 文件后，需要删除旧 Plugin 并重新创建。
该方案适用于哪些场景？
适用于自建 MySQL 迁移到 AWS 时，DMS 的 CDC 复制延迟持续增长无法追平、源库写入 TPS 高需要更高同步吞吐且不能增加源库压力、需要按表将变更数据路由到多个下游系统的场景。
该方案与 DMS 多任务拆分相比有哪些优势？
优势包括：源库 binlog 连接数仅 1 条，对源库性能影响恒定；写入并行度可线性扩展；支持按表路由到 Kafka Topic；全托管运维；端到端延迟 2-10 秒。
