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;
}