Debezium MySQL Connector：DECIMAL列Base64编码值错误求助

核心原因说明 #

当你设置decimal.handling.mode=precise时，Debezium会把DECIMAL类型转换为Java BigDecimal的二进制序列化格式，而非直观的数字字符串。你看到的JxA=正是该二进制数据的Base64编码，这不是错误，只是需要用对应方式解码才能得到原始的100.00。

分步排查与解决 #

• 验证正确解码方式
  用BigDecimal的二进制解析逻辑解码该Base64字符串，示例Java代码：

  import java.math.BigDecimal;
  import java.util.Base64;
  
  public class DecimalDecoder {
      public static void main(String[] args) {
          String base64Str = "JxA=";
          byte[] decodedBytes = Base64.getDecoder().decode(base64Str);
          BigDecimal result = new BigDecimal(decodedBytes);
          System.out.println(result); // 输出100.00
      }
  }
  

  如果是Kafka Connect消费者，确保使用的转换器（如默认JsonConverter）支持解析这种格式；自定义消费者则需手动实现解码逻辑。

• 切换decimal处理模式（快速验证）
  若无需严格高精度，可临时修改配置验证：

  • 设置decimal.handling.mode=string：事件中会直接显示字符串"100.00"
  • 设置decimal.handling.mode=double：事件中显示Double类型的100.0（注意可能丢失精度）

• 检查Schema元数据
  确认连接器生成的Schema中，Total字段的类型为bytes，且携带connect.decimal.precision=10和connect.decimal.scale=2的属性。缺失这些属性会导致客户端无法自动识别并解析DECIMAL类型。

• 核对MySQL驱动版本
  确保使用的mysql-connector-java版本与Debezium版本匹配（如Debezium 2.x对应MySQL 8.0.x驱动），旧版本驱动可能存在DECIMAL类型二进制读取的兼容性问题。

• 确认MySQL binlog配置
  检查MySQL的binlog格式为ROW（Debezium强制要求），且binlog_row_image=FULL。非全量行镜像可能导致DECIMAL字段的二进制数据不完整，引发解析异常。

工具类提示 #

如果用Kafka UI等第三方工具查看事件，默认可能不会自动解析二进制DECIMAL格式，只会显示Base64字符串，这是工具限制而非Debezium错误，需用支持的客户端或手动解码验证。

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