flink cdc同步增量数据timestamp字段相差八小时（分析｜解决）不是粘贴复制的！-爱代码爱编程

问题

我使用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((Long) dbzObj);
                case MicroTimestamp.SCHEMA_NAME:
                    long micro = (long) dbzObj;
                    return TimestampData.fromEpochMillis(micro / 1000, (int) (micro % 1000 * 1000));
                case NanoTimestamp.SCHEMA_NAME:
                    long nano = (long) dbzObj;
                    return TimestampData.fromEpochMillis(nano / 1000_000, (int) (nano % 1000_000));
            }
        }
        LocalDateTime localDateTime = TemporalConversions.toLocalDateTime(dbzObj, serverTimeZone);
        return TimestampData.fromLocalDateTime(localDateTime);
    }

其实意思很简单，就是自定义序列化器（实现接口CustomConverter）并且对timestamp字段进行单独的处理就可以！

总结！！！

关于序列化，flink有一个官方的序列化器，是debezium的，源码下载链接：

你只需要在这个方法里面手动修改时区就可以了！

注意：你要观察下按照你的环境版本timestamp字段映射的对象类型是不是 ZonedDateTime!!!

使用也很简单（好人做到底）：

MySqlSource<DataChangeInfo> mySqlSource = MySqlSource.<DataChangeInfo>builder()
                .hostname("192.168.10.14")
                .port(3306)
                .databaseList("xcode")
                .tableList("xcode.temp_flink")
                .username("root")
                .password("123456")
//                .serverId("5401-5404")
                .debeziumProperties(getProperties())
                .deserializer(new MysqlDeserialization())
//                .scanNewlyAddedTableEnabled(true)
//                .includeSchemaChanges(true) // Configure here and output DDL events
                .startupOptions(StartupOptions.initial())
//                .serverTimeZone("Asia/Shanghai")
                .build();

// 关键代码在这里！！！！！！！！！
private static Properties getProperties() {
    Properties properties = new Properties();
    properties.setProperty("converters", "dateConverters");
    //这里！这里！！这里！！！（这是官方的，用上面的源码自己修改完填你的全路径）
    properties.setProperty("dateConverters.type", "io.debezium.connector.mysql.converters.MysqlDebeziumTimeConverter");
    properties.setProperty("dateConverters.format.date", "yyyy-MM-dd");
    properties.setProperty("dateConverters.format.time", "HH:mm:ss");
    properties.setProperty("dateConverters.format.datetime", "yyyy-MM-dd HH:mm:ss");
    properties.setProperty("dateConverters.format.timestamp", "yyyy-MM-dd HH:mm:ss");
    // timestamp没用。。。
//        properties.setProperty("dateConverters.format.timestamp.zone", "UTC");
    //全局读写锁，可能会影响在线业务，跳过锁设置
    properties.setProperty("debezium.snapshot.locking.mode","none");
    properties.setProperty("include.schema.changes", "true");
    properties.setProperty("bigint.unsigned.handling.mode","long");
    properties.setProperty("decimal.handling.mode","double");
    return properties;
}