共計 3414 個字符,預計需要花費 9 分鐘才能閱讀完成。
本篇內容介紹了“MySQL 流轉工具 Maxwell 的代碼改造和優化方法教程”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓丸趣 TV 小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
Maxwell 是開源產品, 相比 Canal 的體量也小很多,綜合考慮下,在短期內選擇了 Maxwell.
從快速上手到功能支持,算是一個總體支持還不錯的產品,也讓技術調研和迭代進度進展相對快了很多。
一般說要比較,基本都會拿出這幅圖來(數據帶有主觀特點,僅供參考),因為考慮到 bootstrap 是個硬性需求,所以這部分的功能考量也是一個重要權衡。
最近在做數據庫到大數據流轉的過程中發現了 Maxwell 的一些問題和改進點:
1)Maxwell 的服務管理模式目前只支持 start 模式,如果要停止只能采用手工 kill 的方式,相對粗暴一些,當然和作者交流,可以使用信號處理的方式來間接實現。
2)Maxwell 的核心配置是對于同步對象的過濾,可以支持正則等模式,如果過濾規則較為復雜,或者后期不斷的調整,每次調整都需要重新啟動 Maxwell 服務,沒有類似 reload 的模式。
3)對于 DDL 變更,如果 Maxwell 的初始化已完成,服務已啟動,在后續創建一張表的時候,Maxwell 會把變更記錄至 `schemas` 表中維護版本變更記錄,在已有的元數據表中 `tables` 和 `columns` 里面就沒有這些信息了,對于后端的服務解析表結構會帶來一些偏差(DDL 的變更配置會有相應的 JSON)
1. 問題定位
這些問題算起來大多是建議,不算是致命問題,所以整體的進度依然可以繼續推進,但是最近在做了幾張大表的同步之后發現了一些數據問題。
1)bootstrap 的時間比較長,查看 Maxwell 相關監控,整體的數據吞吐量在 800 條 / 秒左右,好像是達到了整個同步的瓶頸,同步一張 200 多萬數據的表需要 1 個小時左右,相對比較長,我們在近期的測試中,幾張千萬級的大表如果串行初始化,差不多得 2 - 3 個小時,實在是太長了。
2)同步數據的時間字段值存在差異,這也是在中端 (maxwell 規劃為中端服務) 和后端 (Flink,Kudu 規劃為后端) 在做數據比對中發現的,bootstrap 的數據比對結果幾乎沒有相同的,也就意味是 bootstrap 在數據方面存在一些潛在問題,所以整個事情輪盤到了 Maxwell 的 bootstrap 部分。
查看代碼邏輯,著實讓我一驚,這個問題目前僅在 bootstrap 的環節出現,比如數據的時間字段值為:
但是經過邏輯處理后,會有時區的計算,會自動補上時區的差異。
現在的問題已經不是初始化帶來的性能隱患,而是數據質量出現了侵入性,導致數據看起來錯亂。
對于這個問題,分析的重點就是時區的處理差異,本來想這個改動應該很小,沒想到調試和環境集成著實花了不少功夫。
2. 問題修正
對于時區的數據差異,主要在于 datetime 數據類型存在時區差異,目前差距在 13 個小時。
查看 Maxwell 的代碼類 SynchronousBootstrapper:
經過調試,需要改動的代碼邏輯范圍是基于函數 setRowValues:
可以修改為:
改動之后,整個 bootstrap 的邏輯經過調試和反復測試就正常了。
3. 性能問題的取舍和修正
當然在這個之外,也做了一些細小的改進。
第一個問題就是 bootstrap 的性能問題,之前看似乎是有瓶頸,吞吐量在 800 左右就上不去了,對此我做了如下的改進:
1).bootstrap 的一個基本原理就是 select * from xxxx order by id; 這種使用模式,如果表數據量比較大,其實 order by 的部分看起來是走了主鍵,該子句會強制走全索引掃描,但是整體的效果反而不是全表掃描,所以我就干脆去除了邏輯中的 order by 子句。
整個邏輯的改造也很輕量:
private ResultSet getAllRows(String databaseName, String tableName, Table table, String whereClause, if ( pk != null !pk.equals() ) { sql += String.format( order by %s , pk); }
2). 去除了寫入數據后的 sleep 1 毫秒
進一步分析代碼,發現 bootstrap 中吞吐量的瓶頸是其中一個詭異的 sleep 1 的處理,根據初步分析,可能考慮到 bootstrap 的任務會產生大量數據,對于帶寬和負載壓力較大,通過 sleep 的方式能夠做到降速,整體可控。
另外對于 bootstrap 的日志統計中會包括同步的數據條數,這個指標值目前的依賴度不高,而且數據校驗的工作目前會先停止 Slave 再進行數據比對
性能提升和改進,在 3 - 5 倍左右,所以這個部分的邏輯我們可以根據實際情況取舍,在我們的流傳設計中,數據都是基于 Slave 端進行流轉的,所以不會對主庫造成沖擊,改動的這個部分的邏輯也很輕巧,注釋掉 sleep(1)即可。
public void performBootstrap(BootstrapTask task, AbstractProducer producer, Long currentSchemaID) throws Exception { producer.push(row); Thread.sleep(1); ++insertedRows;
改動后經過測試和對比,發現性能好了很多,最多的時候能有 6000 多,同樣的初始化不到 15 分鐘左右就全部搞定了。
這樣一些細小的改進也給我們帶來了一些成就感,后續的數據同步規模繼續擴大,也沒有再反饋過數據質量的問題,當然在這個基礎上還有一些工作需要細化。
4. 后續對于 bootstrap 方向的改進
1)使用分片的思路來完善 bootstrap
提高數據提取的效率,對于千萬級以上的大表數據抽取,可以按照區間分段來提取(需要考慮到數據的變更和寫入的影響),目前的邏輯過于僵硬。
private ResultSet getAllRows(String databaseName, String tableName, Table table, String whereClause, Connection connection) throws SQLException { Statement statement = createBatchStatement(connection); String pk = table.getPKString(); String sql = String.format( select * from `%s`.%s , databaseName, tableName); if ( whereClause != null !whereClause.equals() ) { sql += String.format( where %s , whereClause); } if ( pk != null !pk.equals() ) { sql += String.format( order by %s , pk); } return statement.executeQuery(sql); }
2)數據字典索引優化
Maxwell 數據字典的優化,目前的數據字典中,部分 SQL 執行頻率較高,但是從數據庫層面來看是全表掃描,這些細節的地方還需要進一步調整。
比如如下的 SQL 語句:
explain select * from bootstrap where is_complete = 0 and client_id = dts_hb30_130_200_maxwell003 and (started_at is null or started_at = now()) order by isnull(started_at), started_at asc, id asc;
基于業務場景的改進和調整,也讓我們通過真實場景的落地,更好的擁抱開源,并在一定程度上能夠回饋和反哺。
“MySQL 流轉工具 Maxwell 的代碼改造和優化方法教程”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注丸趣 TV 網站,丸趣 TV 小編將為大家輸出更多高質量的實用文章!