MySQL CDC同步缺失删除和中间更新。了解基于binlog的变更数据捕获是如何工作的，它所需的MySQL设置，以及如何可靠地将其导入BigQuery。2026年8月25日，大多数MySQL到数据仓库的管道都遵循相同的模式：定期作业选择行，将其与先前的数据进行比较，并写入差异。这种方法有效，直到它不再有效。周期性同步遗漏的内容基于SELECT的同步仅看到当前存在的内容。它无法知道某一行在两次运行之间存在并被删除，无法看到多次更改的行的中间状态，每次扫描大型表只为找到少量更改的行时，它会对你的生产数据库产生真实负载。变更数据捕获的不同之处变更数据捕获直接从MySQL的二进制日志（binlog）中读取，这是MySQL内部用于复制的相同机制。每个INSERT、UPDATE和DELETE在写入日志时都会按顺序捕获，包含完整的行状态。没有任何内容是通过比较推断出来的。一切都不依赖于批处理作业何时运行。这并不是关于速度的问题。每小时运行一次的CDC管道在根本上仍然比每分钟运行一次的批处理同步更可靠，因为它捕获了发生的所有内容，而不仅仅是最新快照。在MySQL端的必要条件通过binlog进行CDC有真实的前提条件：以ROW格式进行二进制日志记录，并具有完整的行图像。如果binlog_row_image未设置为FULL，DELETE和UPDATE事件将不会携带完整的前/后状态，仅携带应用更改所需的严格内容。这通常对需要完整行的下游消费者不足够。binlog_row_value_options必须不为PARTIAL_JSON。如果它是，更新JSON列时仅记录JSON值内部发生的变化，而不是完整值。默默无闻，并且在与源进行比较之前容易被忽视。复制用户需要REPLICATION SLAVE和REPLICATION CLIENT权限以读取和监视binlog，此外，还需要SELECT、RELOAD 和SHOW DATABASES以进行初始快照。每个连接到数据库的复制客户的唯一server-id，包括你的CDC连接。与现有副本的冲突会导致难以调试的无声故障。binlog保留的时间足够覆盖停机时间。MySQL在可配置窗口（默认30天）后会清除binlog文件。如果你的CDC连接离线超过该时间，它将无法从上次中断的地方恢复。它将需要一个新的初始快照。设置过程GRANT SELECT, RELOAD, SHOW DATABASES, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'your_user'; FLUSH PRIVILEGES; 然后确认你的binlog配置：SHOW VARIABLES LIKE 'log_bin'; SHOW VARIABLES LIKE 'binlog_format'; SHOW VARIABLES LIKE 'binlog_row_image'; 如果其中任何一个未正确设置，则需要放入my.cnf中，并且MySQL需要重启以应用这些设置。完整的连接器文档，包括每个先决条件和故障排除步骤，见于docs.erathos.com/connectors/databases/mysql#cdc-setup。这是一个托管平台发挥其作用的地方。Erathos及类似工具处理快照模式选择（完整的初始快照与仅binlog），服务器ID分配和冲突避免，以及在binlog在连接赶上之前被清除时的恢复逻辑，因此运行管道的人不必每次连接新的源时都手动重建该逻辑。将其导入到BigQuery一旦CDC正确地捕获了更改，目标侧则相对简单：每个更改事件映射到你的BigQuery表中的行操作。值得正确处理的部分不是加载到BigQuery，而是确保到达那里的内容是完整的。一个在时间上加载不完整数据的管道比偶尔延迟几分钟但始终正确的管道更糟。如果你的团队仍在对生产MySQL进行全表批量同步，值得问的问题不是“我们如何提高速度”，而是“我们当前无法看到什么”。如果你想尝试这个实践，可以创建一个Erathos账户，并在几分钟内连接启用CDC的MySQL源。