Flink cdc同步增量数据timestamp字段相差八小时（分析｜解决）不是粘贴复制的！

BUG FIXER

已于 2024-11-27 09:33:41 修改

阅读量983

点赞数 4

CC 4.0 BY-SA版权

于 2024-11-26 17:07:16 首次发布

本文链接：https://blog.csdn.net/JGMa_TiMo/article/details/144062951

问题

我使用flink cdc同步mysql到mysql遇到了timestamp字段缺少八小时的问题。很少无语，flink ,cdc,debezium时区都设置了，没有任何效果！

分析

问题出现在mysql binlog身上！！！
因为默认mysql会使用UTC来存储binlog,你可以使用下方的sql验证：

mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime="2024-11-26 16:20:59" --stop-datetime="2024-11-26 16:30:59" /path/to/binlog-file

设置起止时间和binlog位置

而我们存储mysql数据的时候使用的时区大概率是上海，你也可以查看：

SELECT @@global.time_zone, @@session.time_zone;

如果都是system，而你就在中国大陆那就没错了

验证分析:

而这个时间相差你会发现只在同步增量数据的时候才出现！因为.startupOptions(StartupOptions.initial())会同步历史数据，这些都是从数据库读取的，所以两边都是上海时区就不会有问题！

解决

其实官方给了解决的方案，但是说的非常的模糊，如果对flink cdc不是很熟悉的朋友大概率会云里雾里！
这是官方的常见问题汇总：
以下是原话：
Q2: 使用 MySQL CDC，增量阶段读取出来的 timestamp 字段时区相差8小时，怎么回事呢？

#在解析binlog数据中的timestamp字段时，cdc 会使用到作业里配置的server-time-zone信息，也就是MySQL服务器的时区，如果这个时区没有和你的MySQL服务器时区一致，就会出现这个问题。

此外，如果是在DataStream作业中自定义列化器如 MyDeserializer implements DebeziumDeserializationSchema, 自定义的序列化器在解析 timestamp 类型数据时，需要参考下 RowDataDebeziumDeserializeSchema 中对 timestamp 类型的解析，用时给定的时区信息。


private TimestampData convertToTimestamp(Object dbzObj, Schema schema) {
   
   
        if (dbzObj instanceof Long) {
   
   
            switch (schema.name()) {
   
   
                case Timestamp.SCHEMA_NAME:
                    return TimestampData.fromEpochMillis