binlog是 MySQL 的二进制日志，本质是一份按时间顺序记录所有数据变更操作（DML/DDL）的追加写日志。它不记录查询（SELECT），只记录“让数据真正发生变化”的动作：比如
INSERT、
UPDATE、
DELETE、
CREATE TABLE、
DROP DATABASE等。
它的核心用途不是给开发者看的，而是为可靠性与扩展性服务：主从复制靠它，增量同步靠它，闪回恢复靠它，CDC（变更数据捕获）也靠它。没有
binlog，MySQL 就没法做真正的实时数据分发。
为什么必须开 binlog 才能做主从或 Kafka 同步
因为所有下游组件（无论是从库 Slave，还是
go-mysql-transfer、
canal、
debezium这类工具）都只能通过伪装成“从库”去拉取
binlog—— 它们主动连接 MySQL，发送
COM_BINLOG_DUMP协议请求，然后持续接收流式事件。
如果
log_bin没开启，MySQL 根本不生成任何二进制日志，上游一写，下游就彻底“失明”。这不是配置问题，是能力缺失。
log_bin必须在
my.cnf中显式启用（例如
log_bin = /var/lib/mysql/mysql-bin）
server_id必须设为非 0 整数，且主从不能重复（否则复制线程拒绝启动）
binlog_format强烈建议设为
ROW：Statement 模式在函数、触发器、非确定SQL 下极易丢数据或主从不一致；Mixed 模式行为不可控，调试困难
binlog_row_image = FULL必须开启，否则
UPDATE/
DELETE只记录变更后数据，丢失原始值，导致下游无法准确构建前后镜像
常见同步失败的三个隐藏原因
很多同步任务跑着跑着就卡住或报错，表面看是网络或权限问题，实际根子常在 binlog 配置或生命周期管理上：
expire_logs_days或
binlog_expire_logs_seconds设得太小（比如只保留 1 天），而同步任务因消费延迟、暂停维护等中断超时，再恢复时所需位点（
File+
Position或 GTID set）已被自动清理 → 报错
Could not find first log file name in binary log index file或
Could not execute command: Could not find specified GTID set主库未开启
log_slave_updates（尤其在级联复制或 binlog server 场景下），导致中继节点不把收到的事件再写入自己的
binlog，下游无法继续链式拉取 使用 GTID 模式但没配
gtid_mode = ON+
enforce_gtid_consistency = ON，或从库执行了
SET SQL_LOG_BIN = 0导致 GTID 断连，后续同步直接拒绝
怎么验证 binlog 是否真在工作且可被拉取
别只信配置文件，要动手查真实状态：
登录 MySQL，运行SHOW VARIABLES LIKE 'log_bin';→ 必须返回
ON运行
SHOW MASTER STATUS;→ 能看到当前
File（如
mysql-bin.000042）和
Position（如
1987），说明日志正在滚动写入 用
mysqlbinlog工具本地解析：
mysqlbinlog -v --base64-output=DECODE-ROWS /var/lib/mysql/mysql-bin.000042 | head -20
若能看到
### UPDATE ... ### WHERE @1=... ### SET @1=...这类 ROW 格式输出，说明格式和内容都正常 从另一台机器用
mysqlbinlog --read-from-remote-server尝试直连拉取（需提前授权
REPLICATION SLAVE权限），这是最贴近同步工具真实行为的验证方式
row 格式下一条 update 实际记几条记录
很多人以为一个 SQL 就一条 binlog event，其实不然。以
UPDATE t_user SET name='Alice' WHERE id=100为例，在
binlog_format = ROW+
binlog_row_image = FULL下，MySQL 会记录： 一条
WRITE_ROWS_EVENT（含新值） 一条
UPDATE_ROWS_EVENT（含旧值 + 新值，即完整镜像） 如果开启了
binlog_rows_query_log_events = ON，还会额外附带一条
ROWS_QUERY_EVENT，存原始 SQL 文本（仅用于调试，不参与回放）
这意味着：同样一条 update，在 ROW 模式下产生的日志体积可能是 STATEMENT 模式的 2–3 倍。磁盘 IO、网络带宽、解析 CPU 都会升高，但换来的是100% 可重放、无歧义、支持精确过滤与字段级变更识别——对同步到 Kafka 或 OLAP 系统来说，这点开销值得。
同步链路越长（MySQL → Kafka → Flink → Doris），越不能省略
FULL镜像；否则下游连“这行原来是啥”都不知道，谈不上幂等、补偿或审计。
