MySQL流轉工具Maxwell的代碼改造和優化方法教程

本篇內容介紹了“MySQL流轉工具Maxwell的代碼改造和優化方法教程”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

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的代碼改造和優化方法教程”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！