寫在前面
MySQL是網際網路行業使用的最多的關係型資料庫之一，而且MySQL又是開源的，對於MySQL的深入研究，能夠加深我們對於資料庫原理的理解。自從開源了mykit-data之後，不少小夥伴試用後，反饋mykit-data無法正確的解析MySQL8的binlog。於是我測試了下，mykit-data在解析MySQL5.x的binlog時，沒有啥問題，能夠正確的解析出結果資料。然而，在解析MySQL8.x的binlog時，總是與binlog日誌位數相差12位而導致解析失敗。
文章已收錄到：
https://github.com/sunshinelyz/technology-binghe
https://gitee.com/binghe001/technology-binghe
問題修復
今天太晚了，我還在研究MySQL 8.0.20的原始碼，問題的修復過程後續再寫一篇詳細的文章來與小夥伴們分享下。這裡，我就直接說我是如何解決這個問題的。
MySQL5.x binlog的解析結果與MySQL8.x binlog的解析結果總是存在位數偏差，框架原本的程式碼直接解析MySQL 5.x是沒啥問題的，在解析MySQL 8.x的時候出現位數錯誤。
期間，我幾乎翻閱了MySQL的所有官方文件，把mykit-data中關於解析binlog日誌的功能重新寫了一遍，解析MySQL5.x沒問題，解析MySQL8.x還是錯位。
到底哪裡出了問題呢？就在對於問題的解決一籌莫展的時候，突然，想到一個思路：解決MySQL8.x binlog的時候不是總錯位嗎？那我就把多餘位數的binlog資料讀取出來，直接忽略掉，使後續binlog的解析操作對齊不就行了嗎？
趕緊嘗試一下，於是我在mykit-data框架的原始碼中，新增了如下程式碼。
上面程式碼是對解析MySQL binlog位數的校驗和讀取的封裝，當讀取的binlog位數未達到讀取的限制位數時，一直讀取binlog的資料，直到讀取的binlog位數達到讀取的限制位數位置。具體內部的邏輯，小夥伴們可以閱讀mykit-data的原始碼。
加上這個邏輯後，進行測試驗證，解析MySQL 8.x資料庫的binlog竟然成功了！！困擾我幾天的問題就這麼在不經意間解決了！！
從解決這個問題的結果來看，MySQL8.x的binlog在本質上比MySQL5.x的binlog位數要長，中間會拼接用來分隔不同事件位的標識，我們在解析MySQL8.x的binlog日誌時，可直接忽略掉這些分隔不同事件位的標識，目的就是讓binlog的解析位對齊，從而能夠正確的解析出下一個事件。而這樣處理，也不會影響解析結果。
很多時候就是這樣，當你苦於解決某個問題，遲遲找不到解決方案而一籌莫展時，在某個不經意的瞬間，就會無意中解決這個棘手的問題，但前提是你需要深刻理解它的原理並嘗試各種方式和方法來解決它！
關於mykit-data
mykit-data是一款完全開源的資料異構中介軟體，支援外掛化、視覺化的資料異構框架，支援MySQL到MySQL、MySQL到Oracle、Oracle到MySQL、Oracle到Oracle的全量、實時/定時增量資料同步。完全的外掛化、視覺化操作。通過日誌最大限度的避免同步過程中的資料丟失。支援失敗重試，人工干預，支援檢視同步的資料和詳細的日誌資訊。
目前支援MySQL5.x、MySQL8.x，Oracle 11g及以上版本。後續會以外掛的形式支援更多的異構資料來源。
mykit-data的開源地址如下：
GitHub：https://github.com/sunshinelyz/mykit-data
Gitee：https://gitee.com/binghe001/mykit-data
最後，小夥伴們為這款開源專案點個Star呀！！
好了，今天就到這兒吧，我是冰河，大家有啥問題可以在下方留言，也可以加我微信：sun_shine_lyz，一起交流技術，一起進階，一起牛逼~~