如何修復(fù)解析MySQL8.x binlog錯位的問題

問題修復(fù)

今天太晚了，我還在研究MySQL 8.0.20的源碼，問題的修復(fù)過程后續(xù)再寫一篇詳細(xì)的文章來與小伙伴們分享下。這里，我就直接說我是如何解決這個問題的。

MySQL5.x binlog的解析結(jié)果與MySQL8.x binlog的解析結(jié)果總是存在位數(shù)偏差，框架原本的代碼直接解析MySQL 5.x是沒啥問題的，在解析MySQL 8.x的時候出現(xiàn)位數(shù)錯位的問題。

期間，我?guī)缀醴喠薓ySQL的所有官方文檔，把mykit-data中關(guān)于解析binlog日志的功能重新寫了一遍，解析MySQL5.x沒問題，解析MySQL8.x還是錯位。

到底哪里出了問題呢？就在對于問題的解決一籌莫展的時候，突然，想到一個思路：解決MySQL8.x binlog的時候不是總錯位嗎？那我就把多余位數(shù)的binlog數(shù)據(jù)讀取出來，直接忽略掉，使后續(xù)binlog的解析操作對齊不就行了嗎？

趕緊嘗試一下，于是我在mykit-data框架的源碼中，添加了如下代碼。

 

上面代碼是對解析MySQL binlog位數(shù)的校驗(yàn)和讀取的封裝，當(dāng)讀取的binlog位數(shù)未達(dá)到讀取的限制位數(shù)時，一直讀取binlog的數(shù)據(jù)，直到讀取的binlog位數(shù)達(dá)到讀取的限制位數(shù)位置。具體內(nèi)部的邏輯，小伙伴們可以閱讀mykit-data的源碼。

加上這個邏輯后，進(jìn)行測試驗(yàn)證，解析MySQL 8.x數(shù)據(jù)庫的binlog竟然成功了??！困擾我?guī)滋斓膯栴}就這么在不經(jīng)意間解決了??！

從解決這個問題的結(jié)果來看，MySQL8.x的binlog在本質(zhì)上比MySQL5.x的binlog位數(shù)要長，中間會拼接用來分隔不同事件位的標(biāo)識，我們在解析MySQL8.x的binlog日志時，可直接忽略掉這些分隔不同事件位的標(biāo)識，目的就是讓binlog的解析位對齊，從而能夠正確的解析出下一個事件。而這樣處理，也不會影響解析結(jié)果。

很多時候就是這樣，當(dāng)你苦于解決某個問題，遲遲找不到解決方案而一籌莫展時，在某個不經(jīng)意的瞬間，就會無意中解決這個棘手的問題，但前提是你需要深刻理解它的原理并嘗試各種方式和方法來解決它！

關(guān)于mykit-data

mykit-data是一款完全開源的數(shù)據(jù)異構(gòu)中間件，支持插件化、可視化的數(shù)據(jù)異構(gòu)框架，支持MySQL到MySQL、MySQL到Oracle、Oracle到MySQL、Oracle到Oracle的全量、實(shí)時/定時增量數(shù)據(jù)同步。完全的插件化、可視化操作。通過日志最大限度的避免同步過程中的數(shù)據(jù)丟失。支持失敗重試，人工干預(yù)，支持查看同步的數(shù)據(jù)和詳細(xì)的日志信息。

目前支持MySQL5.x、MySQL8.x，Oracle 11g及以上版本。后續(xù)會以插件的形式支持更多的異構(gòu)數(shù)據(jù)源。例如，后續(xù)會增加：SQL Server、Postgre SQL、Redis、ES、Hadoop、HBase、MongoDB、TiDB等數(shù)據(jù)源。