1、背景:
在我們使用FlinkCDC采集mysql數(shù)據(jù)的時(shí)候,日期類型是我們很常見的類型,但是FlinkCDC讀取出來會(huì)和數(shù)據(jù)庫的日期時(shí)間不一致,情況如下
FlinkCDC獲取的數(shù)據(jù)中create_time字段1694597238000轉(zhuǎn)換為時(shí)間戳2023-09-13 17:27:18
?而數(shù)據(jù)庫中原始數(shù)據(jù)如下,并沒有到下午5點(diǎn),這就導(dǎo)致了FlinkCDC讀出來的時(shí)間和數(shù)據(jù)庫中實(shí)際的時(shí)間不一致的情況,與數(shù)據(jù)庫對(duì)比可以發(fā)現(xiàn),這里的時(shí)間戳與數(shù)據(jù)庫時(shí)間剛好相差了 8 個(gè)小時(shí),在實(shí)際生產(chǎn)中這種情況是不行的
2、 產(chǎn)生這種情況的原因是什么呢?
FlinkCDC底層為Debezium,而Debezium默認(rèn)將MySQL中datetime類型轉(zhuǎn)成UTC的時(shí)間戳,底層的 Debezium 并沒有實(shí)現(xiàn) serverTimeZone 的配置,時(shí)區(qū)是寫死的無法更改,導(dǎo)致數(shù)據(jù)庫中設(shè)置的UTC+8到了FlinkCDC讀取出來相差了8個(gè)小時(shí)文章來源:http://www.zghlxwxcb.cn/news/detail-733155.html
3、如何解決呢
我們可以通過在自定義反序列化器中實(shí)現(xiàn)時(shí)區(qū)的修復(fù),需要提前準(zhǔn)備一個(gè)mysql,本案例版本為Mysql5.7,并且開啟binlog,如何開啟binlog過程如下面的博客文章來源地址http://www.zghlxwxcb.cn/news/detail-733155.html
到了這里,關(guān)于【Flink】FlinkCDC獲取mysql數(shù)據(jù)時(shí)間類型差8小時(shí)時(shí)區(qū)解決方案的文章就介紹完了。如果您還想了解更多內(nèi)容,請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章,希望大家以后多多支持TOY模板網(wǎng)!