背景

問(wèn)題是筆者最近在使用FlinkCDC2.3.0捕獲MySQL binlog日志時(shí)遇到的，MySQL使用的阿里云的RDS，MysqlCDC使用讀賬號(hào)以Initinal模式，任務(wù)已經(jīng)運(yùn)行了一段時(shí)間突然報(bào)的錯(cuò)，之前在使用FlinkCDC時(shí)也曾遇到過(guò)，設(shè)置了一些參數(shù)后沒(méi)有再出現(xiàn)過(guò)，一直比較忙沒(méi)有來(lái)得及總結(jié)下來(lái)。但是今天同事又遇到了同類(lèi)型新的報(bào)錯(cuò)形式。下次也將問(wèn)題記錄下來(lái)備忘，同時(shí)也希望對(duì)大家有幫助。

問(wèn)題

報(bào)錯(cuò)：Caused by: java.lang.IllegalStateException: The connector is trying to read binlog starting at Struct{version=1.6.4.Final,connector=mysql,name=mysql_binlog_source,ts_ms=1686104185098,db=,server_id=0,file=mysql-bin.000702,pos=1255923,row=0}, but this is no longer available on the server. Reconfigure the connector to use a snapshot when needed.

詳細(xì)報(bào)錯(cuò)如下：

分析

很多FlinkCDC的報(bào)錯(cuò)中都會(huì)有SplitFetcher thread 0 received unexpected exception while polling the record這樣一句提示，雖然這是同一功能報(bào)錯(cuò)，但是容易對(duì)大家造成困惑。
在網(wǎng)上尋求幫助時(shí)也造成了麻煩。下面我們來(lái)分析這個(gè)報(bào)錯(cuò)，首先我們來(lái)了解下struct中的數(shù)據(jù)信息的含義，其實(shí)它是MySQL binlog source的元數(shù)據(jù)信息，那他的參數(shù)都是啥玩意呢

{
	version=1.6.4.Final,
	connector=mysql,
	name=mysql_binlog_source,
	ts_ms=1686104185098,
	db=,server_id=0,
	file=mysql-bin.000702,
	pos=1255923,
	row=0
}

version：該binlog source使用的Debezium版本號(hào)，
connector：該binlog source所使用的Debezium connector類(lèi)型
name：該binlog source的名稱，
ts_ms：表示該操作發(fā)生的時(shí)間戳（毫秒級(jí)別），
db：表示該操作所在的數(shù)據(jù)庫(kù)，
server_id：表示執(zhí)行該操作的MySQL服務(wù)器ID，
file：表示該操作所在的二進(jìn)制日志文件名，
pos：表示該操作在該文件中的位置，
row：表示該操作影響的行數(shù)。

看到這里我們知道了這是FlinkCDC在讀取的mysqlbinlong時(shí)在嘗試讀取mysql-bin.000702文件，偏移量為1255923點(diǎn)位時(shí)出問(wèn)題了，這些參數(shù)可以幫助我們定位該數(shù)據(jù)的位置。出啥問(wèn)題了呢？我們繼續(xù)看報(bào)錯(cuò)，報(bào)錯(cuò)說(shuō)這個(gè)點(diǎn)位的快照在當(dāng)前庫(kù)中已經(jīng)不可以用了，那么binlog啥情況下不可用呢，就是被刪了或者丟了情況下不可以用。
那么我們分析什么情況下binlog會(huì)被刪掉呢？這就要看我們數(shù)據(jù)庫(kù)的備份保留策略了，于是我們查看了阿里云RDS上的日志備份保留策略。

我們發(fā)現(xiàn)日志保留7天，但是下面還有一個(gè)本地日志保留策略就是本地的日志只會(huì)保留18個(gè)小時(shí)，時(shí)間一到就會(huì)刪除另外如果文件保留個(gè)數(shù)到達(dá)60個(gè)也會(huì)刪除，還有就是占用空間30%也會(huì)被刪除。但是我們分析了一下并沒(méi)有符合這些條件。于是我在社區(qū)溝通了一下，總結(jié)情況如下：

• 場(chǎng)景1： RDS做了內(nèi)部遷移操作，flink jar作業(yè)使用mysql cdc消費(fèi)mysql數(shù)據(jù)報(bào)錯(cuò)的原因是作業(yè)處理的速度追不上mysql binlog 產(chǎn)生的速度，導(dǎo)致正在讀的位點(diǎn)被清理了
• 場(chǎng)景 2： RDS有日志保留策略，最長(zhǎng)18個(gè)小時(shí)，最大占用30%存儲(chǔ)空間，兩個(gè)條件誰(shuí)先滿足都會(huì)觸發(fā)刪除，如果你寫(xiě)入特別多，超過(guò)30%的存儲(chǔ)空間了，可能binlog日志1小時(shí)就刪除了
• 場(chǎng)景 3： 通過(guò)只讀實(shí)例消費(fèi) CDC 數(shù)據(jù)，RDS的只讀實(shí)例不保證binlog（本地只保留10s，上傳oss），所以 flink cdc 側(cè)不建議連接 RDS 的只讀實(shí)例。只讀實(shí)例一旦作業(yè) Failover 10s 內(nèi)恢復(fù)不過(guò)來(lái)，就會(huì)有這個(gè)異常。只讀實(shí)例判定，rr 開(kāi)頭的就是只讀實(shí)例 rm 開(kāi)頭的就是正常的實(shí)例。
  同時(shí)我們?cè)贔linkCDC官方問(wèn)題集找到了該問(wèn)題部分提示。也是讓查找binlog策略。
  

解決方案

經(jīng)過(guò)上述的了解我們大體知道我們?nèi)N場(chǎng)景都有可能出現(xiàn)，問(wèn)題基本上就是mysql的binlog被清理掉了，CDC找不到點(diǎn)位就報(bào)錯(cuò)了，對(duì)于這種情況我們?nèi)缦氯齻€(gè)操作：

• 分析了任務(wù)的背壓，減少上游source任務(wù)的并行度，增加了下游任務(wù)的并行度，來(lái)緩解背壓，加快任務(wù)處理速度。
• 同時(shí)過(guò)濾掉計(jì)算中不需要的數(shù)據(jù)，來(lái)減少數(shù)據(jù)體量。以加快任務(wù)進(jìn)度。
  通過(guò)上述操作緩解場(chǎng)景1、場(chǎng)景2。
• 另一個(gè)方面，我們將讀賬號(hào)替換為寫(xiě)賬號(hào)，
  防止場(chǎng)景3的情況。
• 最后針對(duì)場(chǎng)景2這種FlinkCDC和阿里云RDS備份策略存在兼容性問(wèn)題造成的bug，我們直接進(jìn)行了全狀態(tài)重啟（即在Initinal模式下重啟任務(wù)）以此跳過(guò)數(shù)據(jù)被刪除的binlog的點(diǎn)位。

總結(jié)

在FlinkCDC的issues,我見(jiàn)到了比較多的人提了問(wèn)題，官方建議mysql 側(cè) binlog文件日期保留長(zhǎng)點(diǎn)但是，依然解決不了問(wèn)題。并且對(duì)于讀賬號(hào)問(wèn)題10s問(wèn)題阿里云官方并未說(shuō)明，筆者也是咨詢大佬才了解到。社區(qū)有人建議試試加這個(gè)配置筆者尚未實(shí)踐debeziumProperties.put("snapshot.mode", "when_needed");，之后考慮加一下試試。如果大家和筆者一樣實(shí)在沒(méi)有辦法就選擇重啟吧。FlinkCDC對(duì)這個(gè)問(wèn)題的優(yōu)化并沒(méi)有很好。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-729273.html

到了這里，關(guān)于Flink CDC報(bào)The connector is trying to read binlog starting at xxx but this is no longer available問(wèn)題解決的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！