MySQL CDC 到 BigQuery：定期同步的盲区
MySQL CDC to BigQuery: what periodic syncs miss, and how binlog avoids it
大多数 MySQL 到数据仓库的管道依赖定时任务进行全表扫描，但这会漏掉行删除和中间状态更新，且给生产库带来巨大压力。基于 binlog 的 CDC 方案直接读取 MySQL 的二进制日志，能按顺序捕获每一条 INSERT、UPDATE 和 DELETE 操作，确保数据完整性。文章详细解析了实现可靠 CDC 所需的 MySQL 配置，包括 ROW 格式、FULL 行镜像以及权限设置，并强调了在 BigQuery 中落地时，数据的准确性远比速度更重要。如果你还在使用全表同步，或许该问问自己：我们到底错过了什么？
如果团队仍在对生产 MySQL 运行全表批处理同步，值得问的问题不是“如何让它更快”，而是“我们目前无法看到什么”。
- karakanb
声明：我是 Bruin (https://github.com/bruin-data/bruin) 的联合创始人，我们是 Erathos 的竞争对手。
这篇文章看起来是一篇相当直白的营销文。不过，我很惊喜地发现了 Erathos，这是个不错的产品！
我个人不太喜欢在 production 环境中使用 CDC。流式数据迁移通常容易让人困惑，而且会导致一些糟糕的数据模式，比如没有审计日志的硬删除、更新或删除操作没有时间戳等，而这些往往也是批量加载无法被利用的原因。它们需要对底层数据库有相当程度的运维理解，而且存在一些像 Erathos 团队在文章中提到的那种陷阱。我们在云平台和开源工具中都提供了 CDC 功能，但如果让我选，我会永远选择带有游标值的增量批量加载，而不是 CDC 连接。
我理解由于组织复杂性或遗留数据库的原因，有时确实必须使用 CDC，但这只是我个人的偏好。
如果有人正在寻找一个作为独立 Go CLI 运行的开源 CDC 工具，可以看看 ingestr: https://github.com/bruin-data/ingestr
- gpaulbagetti
写这篇文章是因为我见过太多次同样的故障模式：一个在仪表盘上看起来运行正常的 MySQL 同步任务，实际上却在几个月里静默地丢弃了删除操作和中间更新，因为它是在比较快照而不是读取 binlog。我试图详细列出 MySQL 端必须满足哪些条件（row image、binlog_row_value_options、server-id、retention），CDC 才能真正完整，而不仅仅是“最终一致”。欢迎大家在评论区就任何一点深入探讨。