mysql数据库binlog是做什么的_mysql数据同步说明

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 镜像；否则下游连“这行原来是啥”都不知道，谈不上幂等、补偿或审计。