Binlog 业务应用场景¶

一、Binlog 是什么¶

Binlog（Binary Log）是 MySQL Server 层的二进制日志，记录所有修改数据的操作（DDL、DML），不记录 SELECT。

三种格式：

格式	记录内容	特点
STATEMENT	SQL 原文	日志小，但函数（NOW()、UUID()）可能主从不一致
ROW	每行变更前后的值	日志大，但精确，推荐
MIXED	混合	MySQL 自动选择

二、典型应用场景¶

1. 主从复制¶

从库拉取主库 Binlog，回放达到数据同步。这是最基础用途。

2. 数据恢复¶

误删表、误删数据，用 mysqlbinlog 工具回放 Binlog 到某个时间点：

mysqlbinlog --start-datetime="2024-01-01 10:00:00" \
            --stop-datetime="2024-01-01 11:00:00" \
            mysql-bin.000123 | mysql -u root -p

3. 缓存更新（旁路缓存）¶

写库后更新缓存，可以： - 业务代码双写（简单但容易不一致）。 - 订阅 Binlog，异步更新缓存：业务写完主库，Canal 把 Binlog 推到 MQ，消费者删/改 Redis。

4. 数据同步到其他存储¶

同步到 ES：MySQL 是源，Binlog 实时更新 ES。
同步到 Hive / Doris：做实时数仓。
同步到 Redis：作为缓存。

5. 业务事件通知¶

订单表变更 → 发 MQ → 通知库存、积分、物流等系统。比"在代码里到处发 MQ"更解耦。

6. 审计与风控¶

记录谁在什么时候改了什么数据，用于合规审计。

三、Canal 工作原理¶

Canal 模拟 MySQL 从库的交互协议：

Canal 向主库发送 dump 协议。
主库把 Binlog 推给 Canal。
Canal 解析 Binlog，封装成消息。
推送到 MQ / Kafka / RocketMQ。
业务系统消费。

MySQL -> Canal -> Kafka -> 消费者（更新 ES / Redis / 其他业务库）

四、注意事项¶

ROW 格式：业务订阅必须用 ROW，否则拿不到行级变更。
幂等消费：Binlog 可能重复推，消费者必须幂等。
顺序：同一个表的变更要按顺序消费（Kafka 按主键 hash）。
延迟：Binlog 订阅是异步的，秒级延迟，不能替代强一致事务。
DDL 处理：表结构变更要兼容，消费者要能处理新旧 schema。

典型架构题

"如何保证 MySQL 和 Redis 数据一致？" 标准答案：先更新 DB，再删缓存；删除失败走 Binlog 重试。