binlog是MySQL按时间顺序记录DML/DDL变更的二进制日志，用于主从复制、增量同步、闪回恢复和CDC；必须开启log_bin并配置server_id、ROW格式及FULL row image才能保障同步可靠性。
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 镜像；否则下游连“这行原来是啥”都不知道，谈不上幂等、补偿或审计。
