如何利用Binlog搭建MySQL增量数据同步链路-mysql教程-PHP中文网

不能只靠 binlog 自己搭，必须用 Canal、Flink CDC 等成熟组件；MySQL 必须配置唯一 server-id 和 binlog_format=ROW，且需专用账号授权 REPLICATION SLAVE/CLIENT 权限，否则同步链路无法启动或静默失败。

如何利用binlog搭建mysql增量数据同步链路

直接说结论：不能只靠 binlog 自己搭，必须用 Canal、Flink CDC 这类成熟消费者组件；否则你得自己解析日志格式、管理位点、处理事务边界、应对 DDL 变更——这些全是生产环境里会反复爆雷的点。

这是所有同步链路的启动开关，缺一不可。很多团队卡在这一步，不是没开 binlog，而是开了但格式不对或 ID 冲突。

server-id 必须是正整数，且在整个复制拓扑中唯一；Canal 或 Flink CDC 作为“假从库”，也得有自己独立的 server-id，不能和真实从库撞车
binlog_format 必须设为 ROW，STATEMENT 和 MIXED 在 UPDATE/DELETE 场景下无法保证行级精确性，下游消费时会丢变更或解析失败
配置必须写进 my.cnf 的 [mysqld] 段，SET GLOBAL log_bin = ON 是无效的，MySQL 5.7+ 直接报错
改完要重启 mysqld，然后执行 SHOW VARIABLES LIKE 'log_bin' 和 SHOW VARIABLES LIKE 'binlog_format' 双重确认

Canal 不是连上去就能读 binlog 的，它需要两个底层权限才能拉取日志流和查询主库状态，少一个都会在连接时抛 ERROR 1227 或卡在 handshake 阶段。

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

建账号命令示例：CREATE USER 'canal'@'%' IDENTIFIED BY 'xxx';
授权命令必须包含：GRANT SELECT, REPLICATION SLAVE, REPLICATION CLIENT ON *.* TO 'canal'@'%';
注意不要漏掉 SELECT——Canal 初始化 instance 时会查 information_schema 获取表结构，没这个权限会静默失败，日志里只显示 “fetch schema failed”
如果 MySQL 开了 lower_case_table_names=1，Canal 的表过滤规则（如 canal.instance.filter.regex）必须全小写，否则匹配不到

Flink CDC 原生支持全量+增量自动切换，不用手动导快照、记位点、切流，但它把复杂度转移到了 checkpoint 配置上。常见问题基本都出在这两个参数没对齐。

scan.startup.mode 设为 initial 时，Flink 会先扫全量再接 binlog；设为 latest-offset 则跳过全量，直接从当前位点消费——选错会导致数据缺失或重复
checkpoint 间隔必须小于 binlog 过期时间（expire_logs_days），否则任务重启后找不到历史日志，报错 Could not find the binlog file
Doris sink 要开启 enable-delete 才能正确处理 DELETE 事件；MySQL source 端若含大字段（如 TEXT），需调大 max_allowed_packet，否则解析中断
DDL 变更（如新增列）默认不透传，需显式打开 scan.incremental.snapshot.enabled 和 schema.change.handling.mode，否则新字段值始终为 null

真正上线后最常崩的不是连不上 MySQL，而是位点漂移、回退失败、跨文件断点续传丢失。binlog 文件轮转、GTID 开关、事务拆分都会让简单 position 失效。

Canal 的 meta.dat 文件存位点，但它只在正常 shutdown 时刷新；进程被 kill -9 或磁盘满会导致位点滞后，重启后重复消费
Flink CDC 的 checkpoint 存的是 binlog filename + position + GTID set（如果启用了 GTID），比纯 position 更健壮，但要求 MySQL server_id 不能变，否则 GTID set 解析失败
大事务（比如单个 UPDATE 影响 50 万行）会被 binlog 拆成多个 event，但 Canal 默认按事务打包返回；如果消费端处理超时未 ack，整个事务会重推，造成下游重复
线上千万别用 PURGE BINARY LOGS 清理日志，除非确认所有消费端已稳定追平；建议用 expire_logs_days 交由 MySQL 自动清理