MySQL主从架构下Debezium读取异常：为何需主库设binlog_row_image=FULL？

核心原因 #

虽然主、从服务器的binlog是各自独立的日志文件，但从库的binlog内容依赖于主库同步过来的变更事件内容。主库的binlog_row_image=MINIMAL设置会导致同步到从库的变更事件仅包含部分列数据，进而引发Debezium解析时的类型不匹配错误。

具体逻辑拆解 #

1. 主从复制的事件流向：
   主库执行数据变更后，会将变更事件写入自身的binlog；随后这些事件会同步到从库的relay log，从库回放relay log中的事件更新本地数据，再根据自身binlog_row_image设置生成自己的binlog。
2. MINIMAL模式的局限性：
   当主库使用binlog_row_image=MINIMAL时，主库binlog中的UPDATE事件仅记录被修改的列和主键列（而非全列数据）。即使从库设置了FULL，从库回放该事件时，生成的binlog中：
   • before镜像仅包含主键（无其他列的原始值）
   • after镜像仅包含主键和被修改的列
3. Debezium解析的依赖：
   Debezium解析binlog时，是根据表结构的列顺序来映射binlog中的列值的。当binlog中的列不完整时，Debezium无法正确匹配列与值的对应关系，最终出现类似“VARCHAR列读取到LocalDateTime类型值”的错位错误——本质是列位置映射混乱。
4. FULL模式的修复作用：
   主库设置binlog_row_image=FULL后，主库binlog中的UPDATE事件会记录完整的before和after行镜像，从库同步后生成的binlog也会包含全列数据，Debezium能正确解析每个列的类型与值，错误自然消失。

避免修改主库设置的可行方案 #

如果担心主库设置FULL会增加存储占用或影响性能，可以尝试以下方向：

• 评估FULL模式的实际影响：
  binlog_row_image=FULL确实会增大binlog体积，但只要主库开启了binlog自动清理（比如配置expire_logs_days），存储占用不会无限增长。建议先在测试环境验证，观察binlog增量和服务器负载变化——多数场景下性能影响可控。
• 检查Azure托管MySQL的特殊配置：
  部分云托管MySQL可能存在主从复制的特殊机制，比如从库是否支持强制生成完整binlog镜像（不受主库配置影响）。可以查阅Azure MySQL官方文档或提交工单咨询。
• 自定义Debezium转换逻辑：
  通过Debezium的transforms扩展，自定义处理不完整的行数据，但这需要编写额外代码，复杂度较高，仅适合特殊场景。

内容的提问来源于stack exchange，提问作者Krishnamurthy Hegde