實(shí)踐：分片、連接、調(diào)優(yōu)全攻略)
先把結(jié)論放在前面如果你的工作里需要頻繁處理“把MySQL某張表的數(shù)據(jù)挪到另一個(gè)地方”無(wú)論目標(biāo)是另一個(gè)MySQL、Hive、MaxCompute還是ElasticsearchDataX的MySQLReader插件都是你值得第一個(gè)吃透的入口。我最早接觸DataX時(shí)也以為它只是個(gè)普通的數(shù)據(jù)同步工具真正用在生產(chǎn)環(huán)境后才意識(shí)到讀插件再怎么門道多終究繞不過對(duì)源端連接、字段映射和分片機(jī)制的準(zhǔn)確理解。這篇就把MySQLReader從原理到實(shí)戰(zhàn)拆開講清楚讓你拿著就能跑通一條任務(wù)。做一個(gè)從零開始的本地同步任務(wù)MySQLReader相當(dāng)于你整個(gè)DataX任務(wù)的“水源”。它不負(fù)責(zé)數(shù)據(jù)最終落到哪里只負(fù)責(zé)把MySQL里的數(shù)據(jù)按你指定的規(guī)則讀出來然后交給框架處理。很多人配置時(shí)報(bào)錯(cuò)、跑得慢問題往往就出在這個(gè)“讀”上面——連接串寫得不對(duì)、字段沒對(duì)上、分片鍵選錯(cuò)全都直接影響下游所有環(huán)節(jié)。1. 先搞清楚DataX到底替你做了什么1.1 從框架視角看MySQLReader的位置DataX的整體模型其實(shí)特別簡(jiǎn)單一個(gè)Job被拆成Reader、Framework、Writer三塊。Reader負(fù)責(zé)從源端取數(shù)Writer負(fù)責(zé)寫到目標(biāo)端Framework負(fù)責(zé)中間的切分、調(diào)度、通道傳輸和流量控制。MySQLReader就是標(biāo)準(zhǔn)Reader接口的一個(gè)實(shí)現(xiàn)它做的事情無(wú)非三件建立JDBC連接、執(zhí)行查詢語(yǔ)句、把ResultSet里的列轉(zhuǎn)換成DataX內(nèi)部的數(shù)據(jù)類型。但真正讓DataX區(qū)別于“寫個(gè)JDBC程序自己導(dǎo)數(shù)據(jù)”的核心能力在Framework那一層——分片?？蚣苣玫饺蝿?wù)的配置后會(huì)根據(jù)reader聲明的分片能力和你給的分片鍵把一個(gè)大的查詢切分成多個(gè)小的查詢片段每個(gè)片段分給一個(gè)并發(fā)Task去跑。MySQLReader能不能充分發(fā)揮多通道并發(fā)的能力就取決于你有沒有給它一個(gè)合格的分片鍵。所以你在看到各種性能對(duì)比時(shí)如果是同一個(gè)MySQL表、同樣的channel數(shù)別人跑3分鐘你跑30分鐘十有八九就是分片配置的差距而不是工具本身的差距。1.2 MySQLReader的本質(zhì)一個(gè)“會(huì)分片的JDBC查詢器”如果你把MySQLReader里的邏輯一層層剝開會(huì)發(fā)現(xiàn)它和你自己寫一個(gè)PreparedStatement查詢沒什么兩樣。核心執(zhí)行過程是根據(jù)傳入的jdbcUrl、username、password建立連接。根據(jù)column信息拼接SELECT 字段 FROM 表 WHERE 條件這樣的SQL。執(zhí)行查詢從ResultSet里循環(huán)取值。將MySQL的數(shù)據(jù)類型轉(zhuǎn)換為DataX的統(tǒng)一類型比如int對(duì)應(yīng)Longdecimal對(duì)應(yīng)Double日期對(duì)應(yīng)Date?？蚣茏龅姆制贛ySQLReader這里是通過改寫SQL里的WHERE條件實(shí)現(xiàn)的。比如原任務(wù)是SELECT id, name FROM user如果分片鍵是id框架會(huì)把任務(wù)拆成WHERE id 1 AND id 1000000、WHERE id 1000000 AND id 2000000這樣多個(gè)區(qū)間分別跑在不同的并發(fā)Task里。這就是為什么分片鍵必須是整數(shù)類型——區(qū)間的起止計(jì)算離不開大小比較和加減步長(zhǎng)。理解了這一點(diǎn)你再看MySQLReader的參數(shù)很多就順理成章了。比如為什么column不推薦寫*因?yàn)榭蚣芤媚憬o的字段去做類型映射和索引對(duì)齊寫*雖然能跑但等于把字段解析主動(dòng)權(quán)交給了數(shù)據(jù)庫(kù)的元數(shù)據(jù)一旦目標(biāo)端結(jié)構(gòu)對(duì)不上排查起來非常頭疼。1.3 本地部署先把能跑的環(huán)境準(zhǔn)備好熱詞里出現(xiàn)了“datax 本地部署”這塊我先按最標(biāo)準(zhǔn)的流程帶你過一遍。DataX目前沒有官方一鍵安裝包那種東西常見做法是直接下載release包或者自己拉源碼編譯推薦普通用戶直接用released包。下載解壓之后目錄結(jié)構(gòu)是這樣的bin存放datax.py等啟動(dòng)腳本。conf核心配置文件主要是日志級(jí)別的配置。pluginReader和Writer所有插件的存放目錄。job官方自帶的示例任務(wù)json。libDataX框架層依賴的jar包。部署的關(guān)鍵點(diǎn)在于下面兩步。第一步確認(rèn)你的機(jī)器裝了JDK 8。注意是JDK 8不是更高版本。DataX這個(gè)項(xiàng)目維護(hù)節(jié)奏不快JDK 11以上跑某些插件會(huì)遇到反射和模塊化相關(guān)的報(bào)錯(cuò)我踩過一次JDK 17的坑后來規(guī)規(guī)矩矩?fù)Q回8。查看版本就用java -version確認(rèn)是1.8開頭。第二步配置DATAX_HOME環(huán)境變量。雖然不配也能跑但后面你寫腳本批量提交任務(wù)時(shí)每次都要去指定絕對(duì)路徑會(huì)很別扭。我一般這樣配export DATAX_HOME/opt/datax export PATH$PATH:$DATAX_HOME/bin配完之后驗(yàn)證環(huán)境最簡(jiǎn)單的辦法是跑一個(gè)官方示例python bin/datax.py job/job.json如果能看到讀數(shù)和寫入的統(tǒng)計(jì)信息、沒有報(bào)錯(cuò)說明你的本地環(huán)境已經(jīng)可以跑DataX了。這里有個(gè)容易忽略的細(xì)節(jié)datax.py依賴Python 2或Python 3都可以但腳本里涉及到print的語(yǔ)法在Python 3下會(huì)自動(dòng)處理兼容所以不用太糾結(jié)版本能執(zhí)行就行。2. 一條MySQLReader任務(wù)的核心配置拆解2.1 job配置骨架真正要改的就三個(gè)地方一條完整DataX任務(wù)的json結(jié)構(gòu)長(zhǎng)這樣{ job: { setting: { speed: { channel: 4 } }, content: [ { reader: { name: mysqlreader, parameter: {} }, writer: { name: streamwriter, parameter: {} } } ] } }初次接觸容易覺得字段多、嵌套深其實(shí)你只要盯住reader的parameter就夠了。MySQLReader里真正需要關(guān)注的參數(shù)一共就這幾個(gè)username、password、column、connection以及可選的where、splitPk、querySql、fetchSize、mandatoryEncoding。我把connection單獨(dú)拿出來說一下。它是一個(gè)數(shù)組數(shù)組里的每個(gè)元素表示一組連接信息包含table、jdbcUrl和datasource。生產(chǎn)環(huán)境中同一個(gè)jdbcUrl底下掛多個(gè)表的情況很常見比如有兩個(gè)庫(kù)連在同一臺(tái)實(shí)例上就可以在一個(gè)connection里配多張表connection: [ { table: [table1, table2], jdbcUrl: [jdbc:mysql://127.0.0.1:3306/db1?useSSLfalseserverTimezoneAsia/Shanghai] }, { table: [table3], jdbcUrl: [jdbc:mysql://127.0.0.1:3306/db2?useSSLfalseserverTimezoneAsia/Shanghai] } ]這個(gè)設(shè)計(jì)在實(shí)際業(yè)務(wù)中非常實(shí)用。比如你有兩張業(yè)務(wù)表在不同庫(kù)但想同時(shí)抽數(shù)不需要寫兩個(gè)任務(wù)一個(gè)任務(wù)里配置兩個(gè)連接元素即可。但要小心框架是按連接元素分別建立連接、并行拉取的如果其中一張表不存在整個(gè)任務(wù)會(huì)直接失敗。2.2 column的三種寫法與坑column的寫法官方給了三種用字段索引[0, 1, 2]0表示第一列。用字段名[id, name, age]。用*表示所有字段。我強(qiáng)烈建議你只用第二種也就是明確的字段名字符串。原因有兩個(gè)一是可讀性好后來維護(hù)的人一眼就知道這張表抽了哪些字段二是順序可控。DataX讀取列后是按column里聲明的順序傳給writer的不是按表結(jié)構(gòu)順序如果目標(biāo)端字段順序和這里不一樣你用字段名字符串同樣能通過調(diào)整列表順序來對(duì)齊。踩過的一個(gè)典型坑字段名里混了個(gè)關(guān)鍵字比如desc或者order。直接寫column: [desc]會(huì)報(bào)SQL語(yǔ)法錯(cuò)誤。解決辦法是用反引號(hào)包起來DataX的MySQLReader支持在字段名里帶反引號(hào)寫成desc反引號(hào)會(huì)原樣拼進(jìn)查詢SQL。同理如果表名或庫(kù)名是保留字也可以在table配置里給表名加上反引號(hào)。關(guān)于寫*我要多說一句。任務(wù)能跑通但在數(shù)據(jù)量和字段較多的場(chǎng)景下你會(huì)失去對(duì)類型映射和字段順序的掌控。特別是后續(xù)做增量同步、字段裁剪時(shí)*會(huì)讓整個(gè)任務(wù)變成一個(gè)“黑盒”除非完全不需要關(guān)心細(xì)節(jié)否則不推薦。2.3 jdbcUrl與連接參數(shù)MySQLReader的jdbcUrl格式看起來簡(jiǎn)單但很多人栽在細(xì)節(jié)上。標(biāo)準(zhǔn)格式j(luò)dbc:mysql://主機(jī)名:端口/數(shù)據(jù)庫(kù)名?參數(shù)生產(chǎn)環(huán)境我必帶的參數(shù)是這兩個(gè)useSSLfalse如果MySQL服務(wù)器沒配SSL證書默認(rèn)驅(qū)動(dòng)行為可能會(huì)去嘗試SSL握手導(dǎo)致連接變慢甚至報(bào)錯(cuò)。本地測(cè)試環(huán)境尤其明顯加上之后連接秒開。serverTimezoneAsia/Shanghai這個(gè)參數(shù)影響的是Java側(cè)解析時(shí)間字段的時(shí)區(qū)。不加的話如果MySQL服務(wù)器時(shí)區(qū)與JVM不一致查出來的datetime字段會(huì)差幾個(gè)小時(shí)。如果你的MySQL是8.0以上還要留意驅(qū)動(dòng)本身的認(rèn)證協(xié)議。DataX官方mysqlreader內(nèi)置的驅(qū)動(dòng)版本比較老如果源庫(kù)用戶用了caching_sha2_password認(rèn)證老驅(qū)動(dòng)會(huì)連不上報(bào)錯(cuò)信息類似“Unable to load authentication plugin”。解決辦法是找到mysqlreader插件的lib目錄把里面的mysql驅(qū)動(dòng)jar換掉換成8.0.20以上版本的就行。這個(gè)我后面在踩坑章節(jié)還會(huì)細(xì)說。還有一個(gè)容易被忽略的點(diǎn)jdbcUrl里的編碼參數(shù)。如果表結(jié)構(gòu)、注釋或數(shù)據(jù)里有emoji這類四字節(jié)字符連接串最好加上characterEncodingutf8mb4否則utf8字符集下部分字符會(huì)變成亂碼或直接寫入失敗。雖然MySQL8默認(rèn)字符集已經(jīng)比較合理但顯式聲明永遠(yuǎn)比依賴默認(rèn)值穩(wěn)妥。2.4 用querySql代替表和列有一種場(chǎng)景用標(biāo)準(zhǔn)table加column配置會(huì)很難受你想對(duì)源端做聚合查詢比如統(tǒng)計(jì)每個(gè)用戶的訂單數(shù)量。這時(shí)候MySQLReader官方提供了querySql參數(shù)你可以直接寫一條查詢SQL作為數(shù)據(jù)源。配置示例parameter: { username: root, password: 123456, querySql: SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE create_time 2024-01-01 GROUP BY user_id, connection: [ { jdbcUrl: [jdbc:mysql://127.0.0.1:3306/business] } ] }注意querySql和table/column是互斥關(guān)系。一旦你寫了querySqlconnection里不需要、也不應(yīng)該再指定table和column?？蚣軙?huì)直接把querySql當(dāng)作查詢語(yǔ)句執(zhí)行然后把結(jié)果集按列順序傳給writer。踩過的一個(gè)教訓(xùn)querySql里的結(jié)果沒有穩(wěn)定排序或唯一鍵時(shí)下游要做斷點(diǎn)續(xù)傳或增量同步會(huì)非常麻煩。建議在任何用querySql的場(chǎng)景下都在SQL里盡量帶上一個(gè)單調(diào)遞增字段并把它放在select列表的第一個(gè)位置方便后續(xù)做核對(duì)與斷點(diǎn)。2.5 where條件與增量同步思路where參數(shù)是MySQLReader用來做同步過濾的配在connection里或parameter根上都可以。它的作用是給查詢SQL追加一個(gè)條件比如where: create_time 2024-06-01 00:00:00加上之后實(shí)際執(zhí)行的查詢變成SELECT ... FROM table WHERE create_time ...。日常使用中最常見的場(chǎng)景就是增量同步。做法一般有兩種第一種簡(jiǎn)單粗暴每天凌晨同步前一天的數(shù)據(jù)把where條件寫成時(shí)間范圍。第二種用系統(tǒng)變量結(jié)合把時(shí)間參數(shù)在提交任務(wù)前動(dòng)態(tài)替換進(jìn)json。比如我習(xí)慣在shell腳本里用sed把json模板里的${bizdate}替換成實(shí)際日期再提交任務(wù)sed -i s/\${bizdate}/2024-06-01/g ./sync_job.json python $DATAX_HOME/bin/datax.py ./sync_job.json這樣做的好處是json模板可復(fù)用、可版本化管理。注意一個(gè)問題where條件如果寫的字段沒有索引會(huì)帶來全表掃描數(shù)據(jù)量大時(shí)同步速度被拖得很明顯。所以where里用的字段盡量是索引字段如果時(shí)間字段沒索引最好配合主鍵分片一起使用別只依賴where來做過濾。3. splitPk分片決定你是跑3分鐘還是30分鐘3.1 沒有splitPk時(shí)會(huì)發(fā)生什么很多人第一次跑DataX任務(wù)配置里根本不寫splitPk任務(wù)也能正常完成就沒放在心上。直到某一天數(shù)據(jù)量漲到千萬(wàn)級(jí)、億級(jí)才發(fā)現(xiàn)任務(wù)跑幾個(gè)小時(shí)都不結(jié)束。原因在于沒有splitPk時(shí)MySQLReader不會(huì)對(duì)查詢做拆分整個(gè)任務(wù)就是一個(gè)單Task在拉全量數(shù)據(jù)。channel配置得再多也沒用源頭只有一個(gè)查詢、一個(gè)連接、一個(gè)ResultSet。你用4個(gè)channel跑和用8個(gè)channel跑區(qū)別只體現(xiàn)在框架內(nèi)部數(shù)據(jù)傳輸?shù)耐ǖ罃?shù)量上源端讀數(shù)的速度不變。所以判斷一個(gè)DataX任務(wù)是否還有優(yōu)化空間第一步就看reader有沒有分片。沒有分片且數(shù)據(jù)量大性能天花板就在那里。3.2 分片原理按主鍵范圍切區(qū)間MySQLReader的splitPk必須是數(shù)值類型通常就是主鍵id或者自增id?？蚣茉谌蝿?wù)啟動(dòng)階段會(huì)做這樣幾件事查詢分片鍵的最小值和最大值SELECT MIN(id), MAX(id) FROM table WHERE ...。根據(jù)channel數(shù)和數(shù)據(jù)范圍把區(qū)間切成N段。每個(gè)Task拿著自己那段的起止id拼接WHERE id ? AND id ?去執(zhí)行查詢。注意區(qū)間是左閉右開的這個(gè)設(shè)計(jì)是為了避免相鄰區(qū)間重復(fù)讀數(shù)據(jù)。比如[min, mid1)和[mid1, mid2)mid1只會(huì)在后一段中被讀取。理解了原理你就能明白為什么splitPk字段推薦主鍵或唯一索引且必須是整數(shù)。因?yàn)榉秶蟹忠蕾嚧笮”容^和算術(shù)運(yùn)算如果字段是字符串類型DataX雖然不會(huì)直接報(bào)錯(cuò)但無(wú)法用字符串去算區(qū)間最終會(huì)退化為不切分。浮點(diǎn)類型理論上可以算但浮點(diǎn)的邊界判斷容易出精度問題實(shí)際中沒人這么用。3.3 選錯(cuò)splitPk的典型翻車現(xiàn)場(chǎng)我見過一次客戶現(xiàn)場(chǎng)翻車表的主鍵是id但業(yè)務(wù)上同步經(jīng)常按時(shí)間范圍過濾他們就把where寫成create_time 2024-01-01這種形式splitPk依然用的id。這種配置看著沒毛病但實(shí)際性能表現(xiàn)忽好忽壞。問題出在數(shù)據(jù)分布上。如果2024-01-01之后的數(shù)據(jù)在id編號(hào)上不是連續(xù)均勻的而是集中在某個(gè)區(qū)間那么框架按id算出來的各個(gè)區(qū)間數(shù)據(jù)量會(huì)嚴(yán)重不均。可能id在1000萬(wàn)到2000萬(wàn)之間數(shù)據(jù)特別密集那分到這段的Task要跑1小時(shí)其他區(qū)間的Task跑幾分鐘就完了整體任務(wù)時(shí)長(zhǎng)被最重的那個(gè)區(qū)間拖住。另一種更隱蔽的問題是如果分片鍵上有大量刪除操作造成的“空洞”MIN和MAX范圍很大但中間實(shí)際數(shù)據(jù)很少區(qū)間切得再多也是空跑。所以選擇splitPk的正確邏輯不只看字段類型還要看字段的單調(diào)性和數(shù)據(jù)分布是否均勻。比較穩(wěn)妥的組合是主鍵作為分片鍵同時(shí)where條件里的時(shí)間字段加上普通索引。如果你想進(jìn)一步提高并行度官方還支持配置多個(gè)分片鍵比如用splitPk配成[id, create_time]框架會(huì)按多個(gè)鍵做組合分片但這種場(chǎng)景較少一般主鍵就夠。3.4 從一張大表實(shí)戰(zhàn)看分片效果舉個(gè)具體數(shù)字。我曾經(jīng)同步一張8000萬(wàn)行的訂單表單次同步總量約20GB。最初沒配splitPk8個(gè)channel全開跑了58分鐘。后來把splitPk配成主鍵id調(diào)整channel為8時(shí)間直接降到12分鐘。再往后加了where條件只同步最近一天數(shù)據(jù)用小腳本按天循環(huán)每天任務(wù)穩(wěn)定在40秒左右。這個(gè)過程充分體現(xiàn)了分片對(duì)源庫(kù)讀取的并行化作用。需要注意不是channel越多越好。如果你本機(jī)CPU只有4核硬開16個(gè)channel線程切換開銷反而會(huì)拖累整體吞吐。一般經(jīng)驗(yàn)是channel的小大參考CPU核心數(shù)的1到2倍同時(shí)結(jié)合目標(biāo)端寫入能力。如果目標(biāo)端是普通MySQL寫入速度有限你開太多channel到后面反而會(huì)出現(xiàn)源端讀得快、目標(biāo)端排隊(duì)等鎖的局面。4. 實(shí)操?gòu)牧闩芡ㄒ粋€(gè)本地同步任務(wù)4.1 一個(gè)能直接抄的完整json下面這份配置我簡(jiǎn)化過目標(biāo)是讀取MySQL里的user_info表輸出到本地控制臺(tái)方便你單測(cè)全鏈路是否通暢。{ job: { setting: { speed: { channel: 2 } }, content: [ { reader: { name: mysqlreader, parameter: { username: root, password: your_password, column: [id, user_name, email, create_time], splitPk: id, where: create_time 2024-01-01 00:00:00, connection: [ { table: [user_info], jdbcUrl: [jdbc:mysql://127.0.0.1:3306/demo?useSSLfalseserverTimezoneAsia/Shanghai] } ] } }, writer: { name: streamwriter, parameter: { print: false } } } ] } }幾個(gè)細(xì)節(jié)我說明一下print設(shè)成false是為了避免大數(shù)據(jù)量時(shí)控制臺(tái)瘋狂刷屏channel先設(shè)2第一跑驗(yàn)證邏輯正確性后面再根據(jù)資源往上加splitPk配了id同時(shí)where里帶時(shí)間條件這種組合在絕大多數(shù)業(yè)務(wù)表上都適用。如果你的源表字段有datetime又配了serverTimezone參數(shù)那么查出來的時(shí)間值會(huì)以該時(shí)區(qū)解析并轉(zhuǎn)成DataX的Date類型。如果目標(biāo)端是另一臺(tái)MySQL建議兩邊時(shí)區(qū)保持一致否則時(shí)間偏差會(huì)一路帶到終點(diǎn)。4.2 本地執(zhí)行與日志解讀把上面的json保存為sync_user.json然后執(zhí)行python $DATAX_HOME/bin/datax.py ./sync_user.json正常跑起來后日志里會(huì)依次出現(xiàn)這幾個(gè)關(guān)鍵信息TODO和jobId任務(wù)被提交生成了一個(gè)jobId。Channel set to 2確認(rèn)通道數(shù)生效。MySQLReader初始化時(shí)的連接信息。每個(gè)Task的啟動(dòng)記錄。結(jié)束時(shí)的統(tǒng)計(jì)信息包括讀取總行數(shù)、寫入總行數(shù)、字節(jié)數(shù)、耗時(shí)等。如果任務(wù)中途報(bào)錯(cuò)日志里會(huì)有Exception堆棧最常見的錯(cuò)誤是連接失敗和字段類型轉(zhuǎn)換錯(cuò)誤。這兩種我放在后面的章節(jié)專門講。還有一個(gè)好習(xí)慣第一跑用很小的數(shù)據(jù)集。可以在where里加上一個(gè)不可能滿足的條件比如WHERE 10這樣任務(wù)不會(huì)讀出任何數(shù)據(jù)但能快速驗(yàn)證你的連接配置、字段配置是否正確。確認(rèn)無(wú)誤后再把條件放開做全量或增量同步。這個(gè)方法生產(chǎn)環(huán)境正式執(zhí)行前非常管用。4.3 快速驗(yàn)證數(shù)據(jù)對(duì)不對(duì)任務(wù)跑完不等于數(shù)據(jù)是對(duì)的。我通常會(huì)做三層校驗(yàn)第一層看行數(shù)。拿DataX日志里的“讀取行數(shù)”和源庫(kù)SELECT COUNT(*)對(duì)比。注意如果where條件沒對(duì)上兩邊行數(shù)差異一眼就能看出來。第二層抽數(shù)比對(duì)。隨機(jī)抽幾條記錄比較源端和目標(biāo)端字段值。這一步對(duì)時(shí)間格式、null值、超長(zhǎng)字符串的感知最直接。第三層查目標(biāo)端重復(fù)率。如果你的目標(biāo)是重新導(dǎo)入一張表且沒有做清表或主鍵去重DataX默認(rèn)不會(huì)幫你做冪等控制重復(fù)執(zhí)行任務(wù)會(huì)插入重復(fù)數(shù)據(jù)。要么先清目標(biāo)表要么用目標(biāo)端writer的writeMode把任務(wù)變成增量寫總之這塊要提前想好。這個(gè)三層校驗(yàn)法我用到現(xiàn)在沒失過手尤其第三層經(jīng)常被人忽略等到任務(wù)定時(shí)調(diào)度跑了一段時(shí)間才發(fā)現(xiàn)目標(biāo)庫(kù)數(shù)據(jù)重復(fù)膨脹那時(shí)候再回頭清理就很痛苦了。5. 性能調(diào)優(yōu)與高級(jí)玩法5.1 fetchSize與流式讀取的真相MySQL JDBC驅(qū)動(dòng)默認(rèn)情況下會(huì)把查詢結(jié)果一次性全部加載到JVM內(nèi)存中。如果你同步千萬(wàn)級(jí)數(shù)據(jù)還沒輪到你處理內(nèi)存就先撐爆了。MySQLReader內(nèi)部處理這個(gè)問題的方式是設(shè)置fetchSize為Integer.MIN_VALUE觸發(fā)驅(qū)動(dòng)切換到流式讀取模式——結(jié)果集一行一行地從服務(wù)端拉到客戶端不會(huì)把所有數(shù)據(jù)囤在內(nèi)存里。這個(gè)機(jī)制也解釋了為什么任務(wù)如果日志中頻繁出現(xiàn)內(nèi)存溢出首先要檢查的不是DataX的JVM參數(shù)而是reader的fetchSize是否被改動(dòng)過。如果你手癢把它改成一個(gè)正數(shù)比如10000驅(qū)動(dòng)會(huì)走分批拉取模式看似內(nèi)存可控但如果ResultSet沒關(guān)閉某些老版本驅(qū)動(dòng)依然可能積累內(nèi)存。所以我的建議是不要主動(dòng)改fetchSize。DataX默認(rèn)處理已經(jīng)是經(jīng)過大量生產(chǎn)驗(yàn)證的流式方案。如果你需要控制內(nèi)存正確姿勢(shì)是調(diào)低channel或者調(diào)低byte限速而不是去動(dòng)fetchSize。5.2 最容易被忽略的channel與byte限速job.setting.speed里有三個(gè)配置容易被搞混channel并發(fā)通道數(shù)。byte每秒字節(jié)限速。record每秒記錄數(shù)限速。byte和record本質(zhì)上是限速器防止同步任務(wù)把源庫(kù)或目標(biāo)庫(kù)的IO打滿。默認(rèn)情況下DataX沒有強(qiáng)烈限速但有些發(fā)行版本會(huì)在job模板里寫上byte: 1048576也就是每秒1MB。如果你沒注意就會(huì)遇到一個(gè)詭異現(xiàn)象無(wú)論怎么調(diào)大channel速度就是上不去。遇到任務(wù)速度不理想第一件事就去檢查speed里是不是有byte或record的數(shù)值。調(diào)試階段可以直接把byte設(shè)成-1表示不限速或者在配置里刪掉速度限制的字段。speed: { channel: 8, byte: -1 }channel和byte不是二選一的關(guān)系channel決定并行的Task數(shù)量byte決定整體流量的上限。只有當(dāng)兩個(gè)都沒有瓶頸時(shí)你的任務(wù)才能跑出接近源端物理上限的速度。5.3 驅(qū)動(dòng)版本與MySQL 8兼容性問題這個(gè)問題值得單獨(dú)拿出來說因?yàn)樗潜镜夭渴鸷蟮谝粋€(gè)高頻坑。DataX官方2015年后更新頻率變慢內(nèi)置的MySQL驅(qū)動(dòng)基本還是5.1.x時(shí)代。當(dāng)你連接MySQL 8實(shí)例時(shí)會(huì)遇到兩類問題一類是認(rèn)證插件不兼容表現(xiàn)為任務(wù)啟動(dòng)時(shí)連接失敗日志里出現(xiàn)Unable to load authentication plugin caching_sha2_password。原因在于MySQL 8默認(rèn)用戶認(rèn)證方式變了老驅(qū)動(dòng)不認(rèn)識(shí)新插件。另一類是時(shí)區(qū)相關(guān)的報(bào)錯(cuò)表現(xiàn)為The server time zone value й?? is unrecognized。這是因?yàn)镸ySQL 8的時(shí)區(qū)設(shè)置返回了中文或特殊格式老驅(qū)動(dòng)解析不了。解決辦法統(tǒng)一是去mysqlreader插件的lib目錄把舊的mysql驅(qū)動(dòng)jar替換成mysql-connector-java-8.0.x.jar。cd $DATAX_HOME/plugin/reader/mysqlreader/libs mv mysql-connector-java-5.1.47.jar mysql-connector-java-5.1.47.jar.bak cp /path/to/mysql-connector-java-8.0.20.jar ./替換完重啟任務(wù)即可。注意jdbcUrl里的連接參數(shù)也可以按照8.0驅(qū)動(dòng)的寫法精簡(jiǎn)useSSL和serverTimezone建議保留。5.4 多表循環(huán)同步的實(shí)用小腳本日常業(yè)務(wù)中更常見的場(chǎng)景不是一張表而是一批表每天同步。寫Python腳本循環(huán)提交DataX任務(wù)是我目前覺得最輕量的方式。import os import json tables [user, order, product] for table in tables: job { job: { setting: {speed: {channel: 4}}, content: [ { reader: { name: mysqlreader, parameter: { username: root, password: 123456, column: [*], connection: [ { table: [table], jdbcUrl: [jdbc:mysql://127.0.0.1:3306/demo?useSSLfalseserverTimezoneAsia/Shanghai] } ] } }, writer: { name: streamwriter, parameter: {print: False} } } ] } } job_file f{table}_job.json with open(job_file, w) as f: json.dump(job, f, ensure_asciiFalse, indent2) os.system(fpython $DATAX_HOME/bin/datax.py {job_file})這里用json.dump生成配置比用sed替換字符串要可靠得多不容易出現(xiàn)JSON語(yǔ)法錯(cuò)誤。如果你要對(duì)每張表單獨(dú)調(diào)整column或where把表名和條件放在一個(gè)統(tǒng)一配置的數(shù)據(jù)結(jié)構(gòu)里維護(hù)成本很低。腳本里我沒做失敗重試實(shí)際生產(chǎn)建議在os.system調(diào)用后檢查返回碼非零則記錄日志并告警。6. 常見問題排查實(shí)錄6.1 任務(wù)秒掛Ex Code 2 / 連接失敗DataX任務(wù)啟動(dòng)后立刻退出日志開頭會(huì)出現(xiàn)一個(gè)比較醒目的錯(cuò)誤碼比如Ex Code: 2。這類問題九成是連接層面的。我總結(jié)了一個(gè)快速排查順序第一步確認(rèn)從執(zhí)行機(jī)器到MySQL的網(wǎng)絡(luò)連通性。在命令行執(zhí)行telnet 127.0.0.1 3306不通就查安全組、防火墻以及MySQL是否只在特定網(wǎng)卡監(jiān)聽。第二步確認(rèn)賬號(hào)權(quán)限。DataX用的賬號(hào)至少要有SELECT權(quán)限如果你用querySql做聚合查詢最好連SHOW VIEW權(quán)限也要有。權(quán)限不足時(shí)日志里會(huì)出現(xiàn)Access denied for user。第三步確認(rèn)jdbcUrl里的主機(jī)名和端口。這里有個(gè)細(xì)節(jié)如果jdbcUrl寫的是localhost而MySQL監(jiān)聽在127.0.0.1有時(shí)會(huì)因?yàn)閟ocket連接方式不同產(chǎn)生怪異問題建議統(tǒng)一寫IP。第四步查時(shí)區(qū)和驅(qū)動(dòng)問題。這個(gè)前面提過MySQL 8場(chǎng)景下優(yōu)先替換驅(qū)動(dòng)并加上serverTimezone參數(shù)。我把這四類問題整理成一張速查表方便你現(xiàn)場(chǎng)對(duì)照現(xiàn)象大概率原因處理辦法Connection refused端口不通或MySQL未啟動(dòng)檢查端口、啟動(dòng)服務(wù)Access denied賬號(hào)權(quán)限不足grant select權(quán)限Authentication plugin報(bào)錯(cuò)MySQL 8認(rèn)證插件不兼容替換驅(qū)動(dòng)為8.xServer time zone unrecognized時(shí)區(qū)解析失敗jdbcUrl加serverTimezoneUnknown database庫(kù)名不對(duì)核對(duì)庫(kù)名大小寫6.2 任務(wù)跑得慢先看channel還是先看限速慢是最難排查的問題因?yàn)樵虺３Ｊ钳B加的。我自己的排查順序是先看日志統(tǒng)計(jì)里的“讀取行數(shù)/秒”和“運(yùn)行耗時(shí)”。如果總行數(shù)不多但耗時(shí)很大大概率是單條查詢本身就慢你去調(diào)并發(fā)沒有意義應(yīng)該去看源庫(kù)的索引和查詢計(jì)劃。如果行數(shù)確實(shí)很大則按下面幾步排查有沒有splitPk。沒有就先加主鍵分片。加完分片還是很慢看有沒有限速參數(shù)。在配置里把byte和record刪除或改成-1。排除了以上兩項(xiàng)看channel數(shù)量。先從CPU核心數(shù)相同的channel開始逐步增加觀察耗時(shí)變化。最后看目標(biāo)端的寫入瓶頸。如果writer是MySQLWriter注意寫入模式下是否有鎖等待如果是HDFSWriter看小文件數(shù)量和網(wǎng)絡(luò)帶寬。有一次我把channel從4調(diào)到16速度反而下降后來排查發(fā)現(xiàn)是目標(biāo)端是一臺(tái)規(guī)格很小的MySQL大量并發(fā)寫入觸發(fā)鎖競(jìng)爭(zhēng)和磁盤刷頁(yè)。這時(shí)候正確的做法是降低channel并開啟writer的批量寫入?yún)?shù)。這類問題提醒我DataX的調(diào)優(yōu)永遠(yuǎn)要看整條鏈路不能只盯著reader端。6.3 類型轉(zhuǎn)換與時(shí)間時(shí)區(qū)錯(cuò)位DataX底層有一套自己的類型系統(tǒng)MySQLReader在讀取時(shí)會(huì)做一次映射MySQL的int、bigint轉(zhuǎn)成Longvarchar、text轉(zhuǎn)成Stringdatetime、timestamp轉(zhuǎn)成Datedecimal轉(zhuǎn)成Double。絕大多數(shù)情況下這個(gè)映射是透明的但有兩個(gè)例外容易踩。第一個(gè)例外是decimal精度。如果源表有decimal(20,4)這種大精度字段轉(zhuǎn)成Double后可能丟失精度。解決辦法是在SQL層面先做處理比如用CAST(decimal_col AS CHAR)把值轉(zhuǎn)成字符串傳給目標(biāo)端再按字符串處理。用querySql時(shí)尤其常用。第二個(gè)例外是時(shí)間字段的時(shí)區(qū)錯(cuò)位?，F(xiàn)象是MySQL里存的是2024-06-01 10:00:00同步到目標(biāo)端變成2024-06-01 18:00:00憑空加了8小時(shí)。原因通常是jdbcUrl里沒配serverTimezoneJava側(cè)用JVM默認(rèn)時(shí)區(qū)解析了字符串而JVM時(shí)區(qū)是UTC或美東時(shí)間。處理方式就是前面反復(fù)強(qiáng)調(diào)的連接串里顯式聲明serverTimezoneAsia/Shanghai。還有一個(gè)冷門情況目標(biāo)端的writer如果也是MySQL且目標(biāo)時(shí)區(qū)和源端一致但仍然差8小時(shí)可以檢查一下驅(qū)動(dòng)連接串兩邊的時(shí)區(qū)參數(shù)是否同時(shí)配置。DataX常見時(shí)間類問題基本都能靠“兩端時(shí)區(qū)統(tǒng)一”解決。6.4 內(nèi)存溢出與超大表處理同步超大表時(shí)內(nèi)存溢出的報(bào)錯(cuò)形態(tài)一般是java.lang.OutOfMemoryError: Java heap space。首先明確一點(diǎn)MySQLReader默認(rèn)流式讀取已經(jīng)大幅降低了內(nèi)存占用所以遇到這個(gè)報(bào)錯(cuò)大概率不是reader把數(shù)據(jù)全裝內(nèi)存里了而是某個(gè)插件或框架環(huán)節(jié)出了問題。我遇到的幾種情況如下第一種writer端把數(shù)據(jù)積壓在內(nèi)存里批量提交。比如某些writer實(shí)現(xiàn)里設(shè)置了batchSize單批次積攢很大才寫一次而channel又很多內(nèi)存就爆了。處理方式通常是調(diào)小channel或調(diào)整writer的batchSize。第二種你改了fetchSize成一個(gè)正數(shù)破壞了流式讀取?；赝说侥J(rèn)即可。第三種JVM堆內(nèi)存實(shí)在太小。DataX啟動(dòng)腳本默認(rèn)的HEAP大小可以通過修改bin/datax.py里的參數(shù)來調(diào)整找到-Xms和-Xmx的值改大一些。但改動(dòng)要克制內(nèi)存分配過大反而容易導(dǎo)致系統(tǒng)整體資源不足。處理超大表還有一層思路不用DataX硬剛?cè)?。如果業(yè)務(wù)允許優(yōu)先做增量同步把全量拆成多天或者多個(gè)分區(qū)sync。DataX本身沒有斷點(diǎn)續(xù)傳能力它傾向于“一次任務(wù)跑完一個(gè)邏輯分片”你與其在內(nèi)存參數(shù)上死磕不如把任務(wù)拆細(xì)、把分片做小。另外提一句DataX任務(wù)重試?？蚣茏詭蝿?wù)通道級(jí)別的重試但整體失敗后默認(rèn)不自動(dòng)重新提交。你可以在外層腳本包一個(gè)重試邏輯失敗時(shí)等幾秒再重啟處理那種偶發(fā)網(wǎng)絡(luò)抖動(dòng)導(dǎo)致的失敗非常有效。7. 一些使用體會(huì)MySQLReader這個(gè)插件我用了兩年多從最初的“只會(huì)照模板改幾個(gè)字段”到后來主動(dòng)靠拆分、限速、驅(qū)動(dòng)調(diào)整來提升同步穩(wěn)定性中間踩了不少坑也積累了一些屬于自己節(jié)奏的經(jīng)驗(yàn)。我比較推薦的做法是每個(gè)同步任務(wù)都盡量保持簡(jiǎn)單和可復(fù)用。能用增量就不用全量能用明確字段就不用星號(hào)能加主鍵分片就一定加。配置json本身就是一個(gè)數(shù)據(jù)同步任務(wù)的唯一文檔寫好它讓后來的人包括三個(gè)月后的自己一看就懂比什么都重要。如果你剛開始接觸DataX先別急著上復(fù)雜場(chǎng)景。拿一臺(tái)本地MySQL造幾十萬(wàn)行數(shù)據(jù)把這篇文章里的配置跑通再逐步加上分片、并發(fā)、多個(gè)連接元素理解每加一個(gè)參數(shù)后日志和速度的變化這套流程走下來你對(duì)數(shù)據(jù)同步工具的理解會(huì)遠(yuǎn)超只會(huì)用導(dǎo)數(shù)據(jù)工具的同行。 DataX MySQLReader插件原理詳解與生產(chǎn)實(shí)踐：分片、連接、調(diào)優(yōu)全攻略
先把結(jié)論放在前面如果你的工作里需要頻繁處理“把MySQL某張表的數(shù)據(jù)挪到另一個(gè)地方”無(wú)論目標(biāo)是另一個(gè)MySQL、Hive、MaxCompute還是ElasticsearchDataX的MySQLReader插件都是你值得第一個(gè)吃透的入口。我最早接觸DataX時(shí)也以為它只是個(gè)普通的數(shù)據(jù)同步工具真正用在生產(chǎn)環(huán)境后才意識(shí)到讀插件再怎么門道多終究繞不過對(duì)源端連接、字段映射和分片機(jī)制的準(zhǔn)確理解。這篇就把MySQLReader從原理到實(shí)戰(zhàn)拆開講清楚讓你拿著就能跑通一條任務(wù)。做一個(gè)從零開始的本地同步任務(wù)MySQLReader相當(dāng)于你整個(gè)DataX任務(wù)的“水源”。它不負(fù)責(zé)數(shù)據(jù)最終落到哪里只負(fù)責(zé)把MySQL里的數(shù)據(jù)按你指定的規(guī)則讀出來然后交給框架處理。很多人配置時(shí)報(bào)錯(cuò)、跑得慢問題往往就出在這個(gè)“讀”上面——連接串寫得不對(duì)、字段沒對(duì)上、分片鍵選錯(cuò)全都直接影響下游所有環(huán)節(jié)。1. 先搞清楚DataX到底替你做了什么1.1 從框架視角看MySQLReader的位置DataX的整體模型其實(shí)特別簡(jiǎn)單一個(gè)Job被拆成Reader、Framework、Writer三塊。Reader負(fù)責(zé)從源端取數(shù)Writer負(fù)責(zé)寫到目標(biāo)端Framework負(fù)責(zé)中間的切分、調(diào)度、通道傳輸和流量控制。MySQLReader就是標(biāo)準(zhǔn)Reader接口的一個(gè)實(shí)現(xiàn)它做的事情無(wú)非三件建立JDBC連接、執(zhí)行查詢語(yǔ)句、把ResultSet里的列轉(zhuǎn)換成DataX內(nèi)部的數(shù)據(jù)類型。但真正讓DataX區(qū)別于“寫個(gè)JDBC程序自己導(dǎo)數(shù)據(jù)”的核心能力在Framework那一層——分片?？蚣苣玫饺蝿?wù)的配置后會(huì)根據(jù)reader聲明的分片能力和你給的分片鍵把一個(gè)大的查詢切分成多個(gè)小的查詢片段每個(gè)片段分給一個(gè)并發(fā)Task去跑。MySQLReader能不能充分發(fā)揮多通道并發(fā)的能力就取決于你有沒有給它一個(gè)合格的分片鍵。所以你在看到各種性能對(duì)比時(shí)如果是同一個(gè)MySQL表、同樣的channel數(shù)別人跑3分鐘你跑30分鐘十有八九就是分片配置的差距而不是工具本身的差距。1.2 MySQLReader的本質(zhì)一個(gè)“會(huì)分片的JDBC查詢器”如果你把MySQLReader里的邏輯一層層剝開會(huì)發(fā)現(xiàn)它和你自己寫一個(gè)PreparedStatement查詢沒什么兩樣。核心執(zhí)行過程是根據(jù)傳入的jdbcUrl、username、password建立連接。根據(jù)column信息拼接SELECT 字段 FROM 表 WHERE 條件這樣的SQL。執(zhí)行查詢從ResultSet里循環(huán)取值。將MySQL的數(shù)據(jù)類型轉(zhuǎn)換為DataX的統(tǒng)一類型比如int對(duì)應(yīng)Longdecimal對(duì)應(yīng)Double日期對(duì)應(yīng)Date?？蚣茏龅姆制贛ySQLReader這里是通過改寫SQL里的WHERE條件實(shí)現(xiàn)的。比如原任務(wù)是SELECT id, name FROM user如果分片鍵是id框架會(huì)把任務(wù)拆成WHERE id 1 AND id 1000000、WHERE id 1000000 AND id 2000000這樣多個(gè)區(qū)間分別跑在不同的并發(fā)Task里。這就是為什么分片鍵必須是整數(shù)類型——區(qū)間的起止計(jì)算離不開大小比較和加減步長(zhǎng)。理解了這一點(diǎn)你再看MySQLReader的參數(shù)很多就順理成章了。比如為什么column不推薦寫*因?yàn)榭蚣芤媚憬o的字段去做類型映射和索引對(duì)齊寫*雖然能跑但等于把字段解析主動(dòng)權(quán)交給了數(shù)據(jù)庫(kù)的元數(shù)據(jù)一旦目標(biāo)端結(jié)構(gòu)對(duì)不上排查起來非常頭疼。1.3 本地部署先把能跑的環(huán)境準(zhǔn)備好熱詞里出現(xiàn)了“datax 本地部署”這塊我先按最標(biāo)準(zhǔn)的流程帶你過一遍。DataX目前沒有官方一鍵安裝包那種東西常見做法是直接下載release包或者自己拉源碼編譯推薦普通用戶直接用released包。下載解壓之后目錄結(jié)構(gòu)是這樣的bin存放datax.py等啟動(dòng)腳本。conf核心配置文件主要是日志級(jí)別的配置。pluginReader和Writer所有插件的存放目錄。job官方自帶的示例任務(wù)json。libDataX框架層依賴的jar包。部署的關(guān)鍵點(diǎn)在于下面兩步。第一步確認(rèn)你的機(jī)器裝了JDK 8。注意是JDK 8不是更高版本。DataX這個(gè)項(xiàng)目維護(hù)節(jié)奏不快JDK 11以上跑某些插件會(huì)遇到反射和模塊化相關(guān)的報(bào)錯(cuò)我踩過一次JDK 17的坑后來規(guī)規(guī)矩矩?fù)Q回8。查看版本就用java -version確認(rèn)是1.8開頭。第二步配置DATAX_HOME環(huán)境變量。雖然不配也能跑但后面你寫腳本批量提交任務(wù)時(shí)每次都要去指定絕對(duì)路徑會(huì)很別扭。我一般這樣配export DATAX_HOME/opt/datax export PATH$PATH:$DATAX_HOME/bin配完之后驗(yàn)證環(huán)境最簡(jiǎn)單的辦法是跑一個(gè)官方示例python bin/datax.py job/job.json如果能看到讀數(shù)和寫入的統(tǒng)計(jì)信息、沒有報(bào)錯(cuò)說明你的本地環(huán)境已經(jīng)可以跑DataX了。這里有個(gè)容易忽略的細(xì)節(jié)datax.py依賴Python 2或Python 3都可以但腳本里涉及到print的語(yǔ)法在Python 3下會(huì)自動(dòng)處理兼容所以不用太糾結(jié)版本能執(zhí)行就行。2. 一條MySQLReader任務(wù)的核心配置拆解2.1 job配置骨架真正要改的就三個(gè)地方一條完整DataX任務(wù)的json結(jié)構(gòu)長(zhǎng)這樣{ job: { setting: { speed: { channel: 4 } }, content: [ { reader: { name: mysqlreader, parameter: {} }, writer: { name: streamwriter, parameter: {} } } ] } }初次接觸容易覺得字段多、嵌套深其實(shí)你只要盯住reader的parameter就夠了。MySQLReader里真正需要關(guān)注的參數(shù)一共就這幾個(gè)username、password、column、connection以及可選的where、splitPk、querySql、fetchSize、mandatoryEncoding。我把connection單獨(dú)拿出來說一下。它是一個(gè)數(shù)組數(shù)組里的每個(gè)元素表示一組連接信息包含table、jdbcUrl和datasource。生產(chǎn)環(huán)境中同一個(gè)jdbcUrl底下掛多個(gè)表的情況很常見比如有兩個(gè)庫(kù)連在同一臺(tái)實(shí)例上就可以在一個(gè)connection里配多張表connection: [ { table: [table1, table2], jdbcUrl: [jdbc:mysql://127.0.0.1:3306/db1?useSSLfalseserverTimezoneAsia/Shanghai] }, { table: [table3], jdbcUrl: [jdbc:mysql://127.0.0.1:3306/db2?useSSLfalseserverTimezoneAsia/Shanghai] } ]這個(gè)設(shè)計(jì)在實(shí)際業(yè)務(wù)中非常實(shí)用。比如你有兩張業(yè)務(wù)表在不同庫(kù)但想同時(shí)抽數(shù)不需要寫兩個(gè)任務(wù)一個(gè)任務(wù)里配置兩個(gè)連接元素即可。但要小心框架是按連接元素分別建立連接、并行拉取的如果其中一張表不存在整個(gè)任務(wù)會(huì)直接失敗。2.2 column的三種寫法與坑column的寫法官方給了三種用字段索引[0, 1, 2]0表示第一列。用字段名[id, name, age]。用*表示所有字段。我強(qiáng)烈建議你只用第二種也就是明確的字段名字符串。原因有兩個(gè)一是可讀性好后來維護(hù)的人一眼就知道這張表抽了哪些字段二是順序可控。DataX讀取列后是按column里聲明的順序傳給writer的不是按表結(jié)構(gòu)順序如果目標(biāo)端字段順序和這里不一樣你用字段名字符串同樣能通過調(diào)整列表順序來對(duì)齊。踩過的一個(gè)典型坑字段名里混了個(gè)關(guān)鍵字比如desc或者order。直接寫column: [desc]會(huì)報(bào)SQL語(yǔ)法錯(cuò)誤。解決辦法是用反引號(hào)包起來DataX的MySQLReader支持在字段名里帶反引號(hào)寫成desc反引號(hào)會(huì)原樣拼進(jìn)查詢SQL。同理如果表名或庫(kù)名是保留字也可以在table配置里給表名加上反引號(hào)。關(guān)于寫*我要多說一句。任務(wù)能跑通但在數(shù)據(jù)量和字段較多的場(chǎng)景下你會(huì)失去對(duì)類型映射和字段順序的掌控。特別是后續(xù)做增量同步、字段裁剪時(shí)*會(huì)讓整個(gè)任務(wù)變成一個(gè)“黑盒”除非完全不需要關(guān)心細(xì)節(jié)否則不推薦。2.3 jdbcUrl與連接參數(shù)MySQLReader的jdbcUrl格式看起來簡(jiǎn)單但很多人栽在細(xì)節(jié)上。標(biāo)準(zhǔn)格式j(luò)dbc:mysql://主機(jī)名:端口/數(shù)據(jù)庫(kù)名?參數(shù)生產(chǎn)環(huán)境我必帶的參數(shù)是這兩個(gè)useSSLfalse如果MySQL服務(wù)器沒配SSL證書默認(rèn)驅(qū)動(dòng)行為可能會(huì)去嘗試SSL握手導(dǎo)致連接變慢甚至報(bào)錯(cuò)。本地測(cè)試環(huán)境尤其明顯加上之后連接秒開。serverTimezoneAsia/Shanghai這個(gè)參數(shù)影響的是Java側(cè)解析時(shí)間字段的時(shí)區(qū)。不加的話如果MySQL服務(wù)器時(shí)區(qū)與JVM不一致查出來的datetime字段會(huì)差幾個(gè)小時(shí)。如果你的MySQL是8.0以上還要留意驅(qū)動(dòng)本身的認(rèn)證協(xié)議。DataX官方mysqlreader內(nèi)置的驅(qū)動(dòng)版本比較老如果源庫(kù)用戶用了caching_sha2_password認(rèn)證老驅(qū)動(dòng)會(huì)連不上報(bào)錯(cuò)信息類似“Unable to load authentication plugin”。解決辦法是找到mysqlreader插件的lib目錄把里面的mysql驅(qū)動(dòng)jar換掉換成8.0.20以上版本的就行。這個(gè)我后面在踩坑章節(jié)還會(huì)細(xì)說。還有一個(gè)容易被忽略的點(diǎn)jdbcUrl里的編碼參數(shù)。如果表結(jié)構(gòu)、注釋或數(shù)據(jù)里有emoji這類四字節(jié)字符連接串最好加上characterEncodingutf8mb4否則utf8字符集下部分字符會(huì)變成亂碼或直接寫入失敗。雖然MySQL8默認(rèn)字符集已經(jīng)比較合理但顯式聲明永遠(yuǎn)比依賴默認(rèn)值穩(wěn)妥。2.4 用querySql代替表和列有一種場(chǎng)景用標(biāo)準(zhǔn)table加column配置會(huì)很難受你想對(duì)源端做聚合查詢比如統(tǒng)計(jì)每個(gè)用戶的訂單數(shù)量。這時(shí)候MySQLReader官方提供了querySql參數(shù)你可以直接寫一條查詢SQL作為數(shù)據(jù)源。配置示例parameter: { username: root, password: 123456, querySql: SELECT user_id, COUNT(*) AS order_cnt FROM orders WHERE create_time 2024-01-01 GROUP BY user_id, connection: [ { jdbcUrl: [jdbc:mysql://127.0.0.1:3306/business] } ] }注意querySql和table/column是互斥關(guān)系。一旦你寫了querySqlconnection里不需要、也不應(yīng)該再指定table和column?？蚣軙?huì)直接把querySql當(dāng)作查詢語(yǔ)句執(zhí)行然后把結(jié)果集按列順序傳給writer。踩過的一個(gè)教訓(xùn)querySql里的結(jié)果沒有穩(wěn)定排序或唯一鍵時(shí)下游要做斷點(diǎn)續(xù)傳或增量同步會(huì)非常麻煩。建議在任何用querySql的場(chǎng)景下都在SQL里盡量帶上一個(gè)單調(diào)遞增字段并把它放在select列表的第一個(gè)位置方便后續(xù)做核對(duì)與斷點(diǎn)。2.5 where條件與增量同步思路where參數(shù)是MySQLReader用來做同步過濾的配在connection里或parameter根上都可以。它的作用是給查詢SQL追加一個(gè)條件比如where: create_time 2024-06-01 00:00:00加上之后實(shí)際執(zhí)行的查詢變成SELECT ... FROM table WHERE create_time ...。日常使用中最常見的場(chǎng)景就是增量同步。做法一般有兩種第一種簡(jiǎn)單粗暴每天凌晨同步前一天的數(shù)據(jù)把where條件寫成時(shí)間范圍。第二種用系統(tǒng)變量結(jié)合把時(shí)間參數(shù)在提交任務(wù)前動(dòng)態(tài)替換進(jìn)json。比如我習(xí)慣在shell腳本里用sed把json模板里的${bizdate}替換成實(shí)際日期再提交任務(wù)sed -i s/\${bizdate}/2024-06-01/g ./sync_job.json python $DATAX_HOME/bin/datax.py ./sync_job.json這樣做的好處是json模板可復(fù)用、可版本化管理。注意一個(gè)問題where條件如果寫的字段沒有索引會(huì)帶來全表掃描數(shù)據(jù)量大時(shí)同步速度被拖得很明顯。所以where里用的字段盡量是索引字段如果時(shí)間字段沒索引最好配合主鍵分片一起使用別只依賴where來做過濾。3. splitPk分片決定你是跑3分鐘還是30分鐘3.1 沒有splitPk時(shí)會(huì)發(fā)生什么很多人第一次跑DataX任務(wù)配置里根本不寫splitPk任務(wù)也能正常完成就沒放在心上。直到某一天數(shù)據(jù)量漲到千萬(wàn)級(jí)、億級(jí)才發(fā)現(xiàn)任務(wù)跑幾個(gè)小時(shí)都不結(jié)束。原因在于沒有splitPk時(shí)MySQLReader不會(huì)對(duì)查詢做拆分整個(gè)任務(wù)就是一個(gè)單Task在拉全量數(shù)據(jù)。channel配置得再多也沒用源頭只有一個(gè)查詢、一個(gè)連接、一個(gè)ResultSet。你用4個(gè)channel跑和用8個(gè)channel跑區(qū)別只體現(xiàn)在框架內(nèi)部數(shù)據(jù)傳輸?shù)耐ǖ罃?shù)量上源端讀數(shù)的速度不變。所以判斷一個(gè)DataX任務(wù)是否還有優(yōu)化空間第一步就看reader有沒有分片。沒有分片且數(shù)據(jù)量大性能天花板就在那里。3.2 分片原理按主鍵范圍切區(qū)間MySQLReader的splitPk必須是數(shù)值類型通常就是主鍵id或者自增id?？蚣茉谌蝿?wù)啟動(dòng)階段會(huì)做這樣幾件事查詢分片鍵的最小值和最大值SELECT MIN(id), MAX(id) FROM table WHERE ...。根據(jù)channel數(shù)和數(shù)據(jù)范圍把區(qū)間切成N段。每個(gè)Task拿著自己那段的起止id拼接WHERE id ? AND id ?去執(zhí)行查詢。注意區(qū)間是左閉右開的這個(gè)設(shè)計(jì)是為了避免相鄰區(qū)間重復(fù)讀數(shù)據(jù)。比如[min, mid1)和[mid1, mid2)mid1只會(huì)在后一段中被讀取。理解了原理你就能明白為什么splitPk字段推薦主鍵或唯一索引且必須是整數(shù)。因?yàn)榉秶蟹忠蕾嚧笮”容^和算術(shù)運(yùn)算如果字段是字符串類型DataX雖然不會(huì)直接報(bào)錯(cuò)但無(wú)法用字符串去算區(qū)間最終會(huì)退化為不切分。浮點(diǎn)類型理論上可以算但浮點(diǎn)的邊界判斷容易出精度問題實(shí)際中沒人這么用。3.3 選錯(cuò)splitPk的典型翻車現(xiàn)場(chǎng)我見過一次客戶現(xiàn)場(chǎng)翻車表的主鍵是id但業(yè)務(wù)上同步經(jīng)常按時(shí)間范圍過濾他們就把where寫成create_time 2024-01-01這種形式splitPk依然用的id。這種配置看著沒毛病但實(shí)際性能表現(xiàn)忽好忽壞。問題出在數(shù)據(jù)分布上。如果2024-01-01之后的數(shù)據(jù)在id編號(hào)上不是連續(xù)均勻的而是集中在某個(gè)區(qū)間那么框架按id算出來的各個(gè)區(qū)間數(shù)據(jù)量會(huì)嚴(yán)重不均。可能id在1000萬(wàn)到2000萬(wàn)之間數(shù)據(jù)特別密集那分到這段的Task要跑1小時(shí)其他區(qū)間的Task跑幾分鐘就完了整體任務(wù)時(shí)長(zhǎng)被最重的那個(gè)區(qū)間拖住。另一種更隱蔽的問題是如果分片鍵上有大量刪除操作造成的“空洞”MIN和MAX范圍很大但中間實(shí)際數(shù)據(jù)很少區(qū)間切得再多也是空跑。所以選擇splitPk的正確邏輯不只看字段類型還要看字段的單調(diào)性和數(shù)據(jù)分布是否均勻。比較穩(wěn)妥的組合是主鍵作為分片鍵同時(shí)where條件里的時(shí)間字段加上普通索引。如果你想進(jìn)一步提高并行度官方還支持配置多個(gè)分片鍵比如用splitPk配成[id, create_time]框架會(huì)按多個(gè)鍵做組合分片但這種場(chǎng)景較少一般主鍵就夠。3.4 從一張大表實(shí)戰(zhàn)看分片效果舉個(gè)具體數(shù)字。我曾經(jīng)同步一張8000萬(wàn)行的訂單表單次同步總量約20GB。最初沒配splitPk8個(gè)channel全開跑了58分鐘。后來把splitPk配成主鍵id調(diào)整channel為8時(shí)間直接降到12分鐘。再往后加了where條件只同步最近一天數(shù)據(jù)用小腳本按天循環(huán)每天任務(wù)穩(wěn)定在40秒左右。這個(gè)過程充分體現(xiàn)了分片對(duì)源庫(kù)讀取的并行化作用。需要注意不是channel越多越好。如果你本機(jī)CPU只有4核硬開16個(gè)channel線程切換開銷反而會(huì)拖累整體吞吐。一般經(jīng)驗(yàn)是channel的小大參考CPU核心數(shù)的1到2倍同時(shí)結(jié)合目標(biāo)端寫入能力。如果目標(biāo)端是普通MySQL寫入速度有限你開太多channel到后面反而會(huì)出現(xiàn)源端讀得快、目標(biāo)端排隊(duì)等鎖的局面。4. 實(shí)操?gòu)牧闩芡ㄒ粋€(gè)本地同步任務(wù)4.1 一個(gè)能直接抄的完整json下面這份配置我簡(jiǎn)化過目標(biāo)是讀取MySQL里的user_info表輸出到本地控制臺(tái)方便你單測(cè)全鏈路是否通暢。{ job: { setting: { speed: { channel: 2 } }, content: [ { reader: { name: mysqlreader, parameter: { username: root, password: your_password, column: [id, user_name, email, create_time], splitPk: id, where: create_time 2024-01-01 00:00:00, connection: [ { table: [user_info], jdbcUrl: [jdbc:mysql://127.0.0.1:3306/demo?useSSLfalseserverTimezoneAsia/Shanghai] } ] } }, writer: { name: streamwriter, parameter: { print: false } } } ] } }幾個(gè)細(xì)節(jié)我說明一下print設(shè)成false是為了避免大數(shù)據(jù)量時(shí)控制臺(tái)瘋狂刷屏channel先設(shè)2第一跑驗(yàn)證邏輯正確性后面再根據(jù)資源往上加splitPk配了id同時(shí)where里帶時(shí)間條件這種組合在絕大多數(shù)業(yè)務(wù)表上都適用。如果你的源表字段有datetime又配了serverTimezone參數(shù)那么查出來的時(shí)間值會(huì)以該時(shí)區(qū)解析并轉(zhuǎn)成DataX的Date類型。如果目標(biāo)端是另一臺(tái)MySQL建議兩邊時(shí)區(qū)保持一致否則時(shí)間偏差會(huì)一路帶到終點(diǎn)。4.2 本地執(zhí)行與日志解讀把上面的json保存為sync_user.json然后執(zhí)行python $DATAX_HOME/bin/datax.py ./sync_user.json正常跑起來后日志里會(huì)依次出現(xiàn)這幾個(gè)關(guān)鍵信息TODO和jobId任務(wù)被提交生成了一個(gè)jobId。Channel set to 2確認(rèn)通道數(shù)生效。MySQLReader初始化時(shí)的連接信息。每個(gè)Task的啟動(dòng)記錄。結(jié)束時(shí)的統(tǒng)計(jì)信息包括讀取總行數(shù)、寫入總行數(shù)、字節(jié)數(shù)、耗時(shí)等。如果任務(wù)中途報(bào)錯(cuò)日志里會(huì)有Exception堆棧最常見的錯(cuò)誤是連接失敗和字段類型轉(zhuǎn)換錯(cuò)誤。這兩種我放在后面的章節(jié)專門講。還有一個(gè)好習(xí)慣第一跑用很小的數(shù)據(jù)集。可以在where里加上一個(gè)不可能滿足的條件比如WHERE 10這樣任務(wù)不會(huì)讀出任何數(shù)據(jù)但能快速驗(yàn)證你的連接配置、字段配置是否正確。確認(rèn)無(wú)誤后再把條件放開做全量或增量同步。這個(gè)方法生產(chǎn)環(huán)境正式執(zhí)行前非常管用。4.3 快速驗(yàn)證數(shù)據(jù)對(duì)不對(duì)任務(wù)跑完不等于數(shù)據(jù)是對(duì)的。我通常會(huì)做三層校驗(yàn)第一層看行數(shù)。拿DataX日志里的“讀取行數(shù)”和源庫(kù)SELECT COUNT(*)對(duì)比。注意如果where條件沒對(duì)上兩邊行數(shù)差異一眼就能看出來。第二層抽數(shù)比對(duì)。隨機(jī)抽幾條記錄比較源端和目標(biāo)端字段值。這一步對(duì)時(shí)間格式、null值、超長(zhǎng)字符串的感知最直接。第三層查目標(biāo)端重復(fù)率。如果你的目標(biāo)是重新導(dǎo)入一張表且沒有做清表或主鍵去重DataX默認(rèn)不會(huì)幫你做冪等控制重復(fù)執(zhí)行任務(wù)會(huì)插入重復(fù)數(shù)據(jù)。要么先清目標(biāo)表要么用目標(biāo)端writer的writeMode把任務(wù)變成增量寫總之這塊要提前想好。這個(gè)三層校驗(yàn)法我用到現(xiàn)在沒失過手尤其第三層經(jīng)常被人忽略等到任務(wù)定時(shí)調(diào)度跑了一段時(shí)間才發(fā)現(xiàn)目標(biāo)庫(kù)數(shù)據(jù)重復(fù)膨脹那時(shí)候再回頭清理就很痛苦了。5. 性能調(diào)優(yōu)與高級(jí)玩法5.1 fetchSize與流式讀取的真相MySQL JDBC驅(qū)動(dòng)默認(rèn)情況下會(huì)把查詢結(jié)果一次性全部加載到JVM內(nèi)存中。如果你同步千萬(wàn)級(jí)數(shù)據(jù)還沒輪到你處理內(nèi)存就先撐爆了。MySQLReader內(nèi)部處理這個(gè)問題的方式是設(shè)置fetchSize為Integer.MIN_VALUE觸發(fā)驅(qū)動(dòng)切換到流式讀取模式——結(jié)果集一行一行地從服務(wù)端拉到客戶端不會(huì)把所有數(shù)據(jù)囤在內(nèi)存里。這個(gè)機(jī)制也解釋了為什么任務(wù)如果日志中頻繁出現(xiàn)內(nèi)存溢出首先要檢查的不是DataX的JVM參數(shù)而是reader的fetchSize是否被改動(dòng)過。如果你手癢把它改成一個(gè)正數(shù)比如10000驅(qū)動(dòng)會(huì)走分批拉取模式看似內(nèi)存可控但如果ResultSet沒關(guān)閉某些老版本驅(qū)動(dòng)依然可能積累內(nèi)存。所以我的建議是不要主動(dòng)改fetchSize。DataX默認(rèn)處理已經(jīng)是經(jīng)過大量生產(chǎn)驗(yàn)證的流式方案。如果你需要控制內(nèi)存正確姿勢(shì)是調(diào)低channel或者調(diào)低byte限速而不是去動(dòng)fetchSize。5.2 最容易被忽略的channel與byte限速job.setting.speed里有三個(gè)配置容易被搞混channel并發(fā)通道數(shù)。byte每秒字節(jié)限速。record每秒記錄數(shù)限速。byte和record本質(zhì)上是限速器防止同步任務(wù)把源庫(kù)或目標(biāo)庫(kù)的IO打滿。默認(rèn)情況下DataX沒有強(qiáng)烈限速但有些發(fā)行版本會(huì)在job模板里寫上byte: 1048576也就是每秒1MB。如果你沒注意就會(huì)遇到一個(gè)詭異現(xiàn)象無(wú)論怎么調(diào)大channel速度就是上不去。遇到任務(wù)速度不理想第一件事就去檢查speed里是不是有byte或record的數(shù)值。調(diào)試階段可以直接把byte設(shè)成-1表示不限速或者在配置里刪掉速度限制的字段。speed: { channel: 8, byte: -1 }channel和byte不是二選一的關(guān)系channel決定并行的Task數(shù)量byte決定整體流量的上限。只有當(dāng)兩個(gè)都沒有瓶頸時(shí)你的任務(wù)才能跑出接近源端物理上限的速度。5.3 驅(qū)動(dòng)版本與MySQL 8兼容性問題這個(gè)問題值得單獨(dú)拿出來說因?yàn)樗潜镜夭渴鸷蟮谝粋€(gè)高頻坑。DataX官方2015年后更新頻率變慢內(nèi)置的MySQL驅(qū)動(dòng)基本還是5.1.x時(shí)代。當(dāng)你連接MySQL 8實(shí)例時(shí)會(huì)遇到兩類問題一類是認(rèn)證插件不兼容表現(xiàn)為任務(wù)啟動(dòng)時(shí)連接失敗日志里出現(xiàn)Unable to load authentication plugin caching_sha2_password。原因在于MySQL 8默認(rèn)用戶認(rèn)證方式變了老驅(qū)動(dòng)不認(rèn)識(shí)新插件。另一類是時(shí)區(qū)相關(guān)的報(bào)錯(cuò)表現(xiàn)為The server time zone value й?? is unrecognized。這是因?yàn)镸ySQL 8的時(shí)區(qū)設(shè)置返回了中文或特殊格式老驅(qū)動(dòng)解析不了。解決辦法統(tǒng)一是去mysqlreader插件的lib目錄把舊的mysql驅(qū)動(dòng)jar替換成mysql-connector-java-8.0.x.jar。cd $DATAX_HOME/plugin/reader/mysqlreader/libs mv mysql-connector-java-5.1.47.jar mysql-connector-java-5.1.47.jar.bak cp /path/to/mysql-connector-java-8.0.20.jar ./替換完重啟任務(wù)即可。注意jdbcUrl里的連接參數(shù)也可以按照8.0驅(qū)動(dòng)的寫法精簡(jiǎn)useSSL和serverTimezone建議保留。5.4 多表循環(huán)同步的實(shí)用小腳本日常業(yè)務(wù)中更常見的場(chǎng)景不是一張表而是一批表每天同步。寫Python腳本循環(huán)提交DataX任務(wù)是我目前覺得最輕量的方式。import os import json tables [user, order, product] for table in tables: job { job: { setting: {speed: {channel: 4}}, content: [ { reader: { name: mysqlreader, parameter: { username: root, password: 123456, column: [*], connection: [ { table: [table], jdbcUrl: [jdbc:mysql://127.0.0.1:3306/demo?useSSLfalseserverTimezoneAsia/Shanghai] } ] } }, writer: { name: streamwriter, parameter: {print: False} } } ] } } job_file f{table}_job.json with open(job_file, w) as f: json.dump(job, f, ensure_asciiFalse, indent2) os.system(fpython $DATAX_HOME/bin/datax.py {job_file})這里用json.dump生成配置比用sed替換字符串要可靠得多不容易出現(xiàn)JSON語(yǔ)法錯(cuò)誤。如果你要對(duì)每張表單獨(dú)調(diào)整column或where把表名和條件放在一個(gè)統(tǒng)一配置的數(shù)據(jù)結(jié)構(gòu)里維護(hù)成本很低。腳本里我沒做失敗重試實(shí)際生產(chǎn)建議在os.system調(diào)用后檢查返回碼非零則記錄日志并告警。6. 常見問題排查實(shí)錄6.1 任務(wù)秒掛Ex Code 2 / 連接失敗DataX任務(wù)啟動(dòng)后立刻退出日志開頭會(huì)出現(xiàn)一個(gè)比較醒目的錯(cuò)誤碼比如Ex Code: 2。這類問題九成是連接層面的。我總結(jié)了一個(gè)快速排查順序第一步確認(rèn)從執(zhí)行機(jī)器到MySQL的網(wǎng)絡(luò)連通性。在命令行執(zhí)行telnet 127.0.0.1 3306不通就查安全組、防火墻以及MySQL是否只在特定網(wǎng)卡監(jiān)聽。第二步確認(rèn)賬號(hào)權(quán)限。DataX用的賬號(hào)至少要有SELECT權(quán)限如果你用querySql做聚合查詢最好連SHOW VIEW權(quán)限也要有。權(quán)限不足時(shí)日志里會(huì)出現(xiàn)Access denied for user。第三步確認(rèn)jdbcUrl里的主機(jī)名和端口。這里有個(gè)細(xì)節(jié)如果jdbcUrl寫的是localhost而MySQL監(jiān)聽在127.0.0.1有時(shí)會(huì)因?yàn)閟ocket連接方式不同產(chǎn)生怪異問題建議統(tǒng)一寫IP。第四步查時(shí)區(qū)和驅(qū)動(dòng)問題。這個(gè)前面提過MySQL 8場(chǎng)景下優(yōu)先替換驅(qū)動(dòng)并加上serverTimezone參數(shù)。我把這四類問題整理成一張速查表方便你現(xiàn)場(chǎng)對(duì)照現(xiàn)象大概率原因處理辦法Connection refused端口不通或MySQL未啟動(dòng)檢查端口、啟動(dòng)服務(wù)Access denied賬號(hào)權(quán)限不足grant select權(quán)限Authentication plugin報(bào)錯(cuò)MySQL 8認(rèn)證插件不兼容替換驅(qū)動(dòng)為8.xServer time zone unrecognized時(shí)區(qū)解析失敗jdbcUrl加serverTimezoneUnknown database庫(kù)名不對(duì)核對(duì)庫(kù)名大小寫6.2 任務(wù)跑得慢先看channel還是先看限速慢是最難排查的問題因?yàn)樵虺３Ｊ钳B加的。我自己的排查順序是先看日志統(tǒng)計(jì)里的“讀取行數(shù)/秒”和“運(yùn)行耗時(shí)”。如果總行數(shù)不多但耗時(shí)很大大概率是單條查詢本身就慢你去調(diào)并發(fā)沒有意義應(yīng)該去看源庫(kù)的索引和查詢計(jì)劃。如果行數(shù)確實(shí)很大則按下面幾步排查有沒有splitPk。沒有就先加主鍵分片。加完分片還是很慢看有沒有限速參數(shù)。在配置里把byte和record刪除或改成-1。排除了以上兩項(xiàng)看channel數(shù)量。先從CPU核心數(shù)相同的channel開始逐步增加觀察耗時(shí)變化。最后看目標(biāo)端的寫入瓶頸。如果writer是MySQLWriter注意寫入模式下是否有鎖等待如果是HDFSWriter看小文件數(shù)量和網(wǎng)絡(luò)帶寬。有一次我把channel從4調(diào)到16速度反而下降后來排查發(fā)現(xiàn)是目標(biāo)端是一臺(tái)規(guī)格很小的MySQL大量并發(fā)寫入觸發(fā)鎖競(jìng)爭(zhēng)和磁盤刷頁(yè)。這時(shí)候正確的做法是降低channel并開啟writer的批量寫入?yún)?shù)。這類問題提醒我DataX的調(diào)優(yōu)永遠(yuǎn)要看整條鏈路不能只盯著reader端。6.3 類型轉(zhuǎn)換與時(shí)間時(shí)區(qū)錯(cuò)位DataX底層有一套自己的類型系統(tǒng)MySQLReader在讀取時(shí)會(huì)做一次映射MySQL的int、bigint轉(zhuǎn)成Longvarchar、text轉(zhuǎn)成Stringdatetime、timestamp轉(zhuǎn)成Datedecimal轉(zhuǎn)成Double。絕大多數(shù)情況下這個(gè)映射是透明的但有兩個(gè)例外容易踩。第一個(gè)例外是decimal精度。如果源表有decimal(20,4)這種大精度字段轉(zhuǎn)成Double后可能丟失精度。解決辦法是在SQL層面先做處理比如用CAST(decimal_col AS CHAR)把值轉(zhuǎn)成字符串傳給目標(biāo)端再按字符串處理。用querySql時(shí)尤其常用。第二個(gè)例外是時(shí)間字段的時(shí)區(qū)錯(cuò)位?，F(xiàn)象是MySQL里存的是2024-06-01 10:00:00同步到目標(biāo)端變成2024-06-01 18:00:00憑空加了8小時(shí)。原因通常是jdbcUrl里沒配serverTimezoneJava側(cè)用JVM默認(rèn)時(shí)區(qū)解析了字符串而JVM時(shí)區(qū)是UTC或美東時(shí)間。處理方式就是前面反復(fù)強(qiáng)調(diào)的連接串里顯式聲明serverTimezoneAsia/Shanghai。還有一個(gè)冷門情況目標(biāo)端的writer如果也是MySQL且目標(biāo)時(shí)區(qū)和源端一致但仍然差8小時(shí)可以檢查一下驅(qū)動(dòng)連接串兩邊的時(shí)區(qū)參數(shù)是否同時(shí)配置。DataX常見時(shí)間類問題基本都能靠“兩端時(shí)區(qū)統(tǒng)一”解決。6.4 內(nèi)存溢出與超大表處理同步超大表時(shí)內(nèi)存溢出的報(bào)錯(cuò)形態(tài)一般是java.lang.OutOfMemoryError: Java heap space。首先明確一點(diǎn)MySQLReader默認(rèn)流式讀取已經(jīng)大幅降低了內(nèi)存占用所以遇到這個(gè)報(bào)錯(cuò)大概率不是reader把數(shù)據(jù)全裝內(nèi)存里了而是某個(gè)插件或框架環(huán)節(jié)出了問題。我遇到的幾種情況如下第一種writer端把數(shù)據(jù)積壓在內(nèi)存里批量提交。比如某些writer實(shí)現(xiàn)里設(shè)置了batchSize單批次積攢很大才寫一次而channel又很多內(nèi)存就爆了。處理方式通常是調(diào)小channel或調(diào)整writer的batchSize。第二種你改了fetchSize成一個(gè)正數(shù)破壞了流式讀取?；赝说侥J(rèn)即可。第三種JVM堆內(nèi)存實(shí)在太小。DataX啟動(dòng)腳本默認(rèn)的HEAP大小可以通過修改bin/datax.py里的參數(shù)來調(diào)整找到-Xms和-Xmx的值改大一些。但改動(dòng)要克制內(nèi)存分配過大反而容易導(dǎo)致系統(tǒng)整體資源不足。處理超大表還有一層思路不用DataX硬剛?cè)?。如果業(yè)務(wù)允許優(yōu)先做增量同步把全量拆成多天或者多個(gè)分區(qū)sync。DataX本身沒有斷點(diǎn)續(xù)傳能力它傾向于“一次任務(wù)跑完一個(gè)邏輯分片”你與其在內(nèi)存參數(shù)上死磕不如把任務(wù)拆細(xì)、把分片做小。另外提一句DataX任務(wù)重試?？蚣茏詭蝿?wù)通道級(jí)別的重試但整體失敗后默認(rèn)不自動(dòng)重新提交。你可以在外層腳本包一個(gè)重試邏輯失敗時(shí)等幾秒再重啟處理那種偶發(fā)網(wǎng)絡(luò)抖動(dòng)導(dǎo)致的失敗非常有效。7. 一些使用體會(huì)MySQLReader這個(gè)插件我用了兩年多從最初的“只會(huì)照模板改幾個(gè)字段”到后來主動(dòng)靠拆分、限速、驅(qū)動(dòng)調(diào)整來提升同步穩(wěn)定性中間踩了不少坑也積累了一些屬于自己節(jié)奏的經(jīng)驗(yàn)。我比較推薦的做法是每個(gè)同步任務(wù)都盡量保持簡(jiǎn)單和可復(fù)用。能用增量就不用全量能用明確字段就不用星號(hào)能加主鍵分片就一定加。配置json本身就是一個(gè)數(shù)據(jù)同步任務(wù)的唯一文檔寫好它讓后來的人包括三個(gè)月后的自己一看就懂比什么都重要。如果你剛開始接觸DataX先別急著上復(fù)雜場(chǎng)景。拿一臺(tái)本地MySQL造幾十萬(wàn)行數(shù)據(jù)把這篇文章里的配置跑通再逐步加上分片、并發(fā)、多個(gè)連接元素理解每加一個(gè)參數(shù)后日志和速度的變化這套流程走下來你對(duì)數(shù)據(jù)同步工具的理解會(huì)遠(yuǎn)超只會(huì)用導(dǎo)數(shù)據(jù)工具的同行。