MySQL流轉(zhuǎn)工具Maxwell的代碼改造和優(yōu)化方法教程

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

Maxwell是開源產(chǎn)品,相比Canal的體量也小很多，綜合考慮下，在短期內(nèi)選擇了Maxwell.

從快速上手到功能支持，算是一個總體支持還不錯的產(chǎn)品，也讓技術調(diào)研和迭代進度進展相對快了很多。

一般說要比較，基本都會拿出這幅圖來(數(shù)據(jù)帶有主觀特點，僅供參考)，因為考慮到bootstrap是個硬性需求，所以這部分的功能考量也是一個重要權衡。

最近在做數(shù)據(jù)庫到大數(shù)據(jù)流轉(zhuǎn)的過程中發(fā)現(xiàn)了Maxwell的一些問題和改進點：

1)Maxwell的服務管理模式目前只支持start模式，如果要停止只能采用手工kill的方式，相對粗暴一些，當然和作者交流，可以使用信號處理的方式來間接實現(xiàn)。

2)Maxwell的核心配置是對于同步對象的過濾，可以支持正則等模式，如果過濾規(guī)則較為復雜，或者后期不斷的調(diào)整，每次調(diào)整都需要重新啟動Maxwell服務，沒有類似reload的模式。

3)對于DDL變更，如果Maxwell的初始化已完成，服務已啟動，在后續(xù)創(chuàng)建一張表的時候，Maxwell會把變更記錄至`schemas`表中維護版本變更記錄，在已有的元數(shù)據(jù)表中`tables`和`columns`里面就沒有這些信息了，對于后端的服務解析表結(jié)構(gòu)會帶來一些偏差(DDL的變更配置會有相應的JSON)

1.問題定位

這些問題算起來大多是建議，不算是致命問題，所以整體的進度依然可以繼續(xù)推進，但是最近在做了幾張大表的同步之后發(fā)現(xiàn)了一些數(shù)據(jù)問題。

1)bootstrap的時間比較長，查看Maxwell相關監(jiān)控，整體的數(shù)據(jù)吞吐量在800條/秒左右，好像是達到了整個同步的瓶頸，同步一張200多萬數(shù)據(jù)的表需要1個小時左右，相對比較長，我們在近期的測試中，幾張千萬級的大表如果串行初始化，差不多得2-3個小時，實在是太長了。

2)同步數(shù)據(jù)的時間字段值存在差異，這也是在中端(maxwell規(guī)劃為中端服務)和后端(Flink,Kudu規(guī)劃為后端)在做數(shù)據(jù)比對中發(fā)現(xiàn)的，bootstrap的數(shù)據(jù)比對結(jié)果幾乎沒有相同的，也就意味是bootstrap在數(shù)據(jù)方面存在一些潛在問題，所以整個事情輪盤到了Maxwell的bootstrap部分。

查看代碼邏輯，著實讓我一驚，這個問題目前僅在bootstrap的環(huán)節(jié)出現(xiàn)，比如數(shù)據(jù)的時間字段值為：

但是經(jīng)過邏輯處理后，會有時區(qū)的計算，會自動補上時區(qū)的差異。

現(xiàn)在的問題已經(jīng)不是初始化帶來的性能隱患，而是數(shù)據(jù)質(zhì)量出現(xiàn)了侵入性，導致數(shù)據(jù)看起來錯亂。

對于這個問題，分析的重點就是時區(qū)的處理差異，本來想這個改動應該很小，沒想到調(diào)試和環(huán)境集成著實花了不少功夫。

2.問題修正

對于時區(qū)的數(shù)據(jù)差異，主要在于datetime數(shù)據(jù)類型存在時區(qū)差異，目前差距在13個小時。

查看Maxwell的代碼類SynchronousBootstrapper：

經(jīng)過調(diào)試，需要改動的代碼邏輯范圍是基于函數(shù)setRowValues：

可以修改為：

改動之后，整個bootstrap的邏輯經(jīng)過調(diào)試和反復測試就正常了。

3.性能問題的取舍和修正

當然在這個之外，也做了一些細小的改進。

第一個問題就是bootstrap的性能問題，之前看似乎是有瓶頸，吞吐量在800左右就上不去了，對此我做了如下的改進：

1).bootstrap的一個基本原理就是select * from xxxx order by id;這種使用模式，如果表數(shù)據(jù)量比較大，其實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).去除了寫入數(shù)據(jù)后的sleep 1毫秒

進一步分析代碼，發(fā)現(xiàn)bootstrap中吞吐量的瓶頸是其中一個詭異的sleep  1的處理，根據(jù)初步分析，可能考慮到bootstrap的任務會產(chǎn)生大量數(shù)據(jù)，對于帶寬和負載壓力較大，通過sleep的方式能夠做到降速，整體可控。

另外對于bootstrap的日志統(tǒng)計中會包括同步的數(shù)據(jù)條數(shù)，這個指標值目前的依賴度不高，而且數(shù)據(jù)校驗的工作目前會先停止Slave再進行數(shù)據(jù)比對

性能提升和改進，在3-5倍左右，所以這個部分的邏輯我們可以根據(jù)實際情況取舍，在我們的流傳設計中，數(shù)據(jù)都是基于Slave端進行流轉(zhuǎn)的，所以不會對主庫造成沖擊，改動的這個部分的邏輯也很輕巧，注釋掉sleep(1)即可。

public void performBootstrap(BootstrapTask task, AbstractProducer producer, Long currentSchemaID) throws Exception {                producer.push(row);                Thread.sleep(1);                ++insertedRows;

改動后經(jīng)過測試和對比，發(fā)現(xiàn)性能好了很多，最多的時候能有6000多，同樣的初始化不到15分鐘左右就全部搞定了。

這樣一些細小的改進也給我們帶來了一些成就感，后續(xù)的數(shù)據(jù)同步規(guī)模繼續(xù)擴大，也沒有再反饋過數(shù)據(jù)質(zhì)量的問題，當然在這個基礎上還有一些工作需要細化。

4.后續(xù)對于bootstrap方向的改進

1)使用分片的思路來完善bootstrap

提高數(shù)據(jù)提取的效率，對于千萬級以上的大表數(shù)據(jù)抽取，可以按照區(qū)間分段來提取(需要考慮到數(shù)據(jù)的變更和寫入的影響)，目前的邏輯過于僵硬。

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)數(shù)據(jù)字典索引優(yōu)化

Maxwell數(shù)據(jù)字典的優(yōu)化，目前的數(shù)據(jù)字典中，部分SQL執(zhí)行頻率較高，但是從數(shù)據(jù)庫層面來看是全表掃描，這些細節(jié)的地方還需要進一步調(diào)整。

比如如下的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;

基于業(yè)務場景的改進和調(diào)整，也讓我們通過真實場景的落地，更好的擁抱開源，并在一定程度上能夠回饋和反哺。

“MySQL流轉(zhuǎn)工具Maxwell的代碼改造和優(yōu)化方法教程”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！