用公司的實際業務記錄一下數據從MySQL導入TIDB的過程以及遇到的問題.
大體流程:用mydumper命令將MySQL的數據轉存為 .sql文件,再用tidb-importer,tidb-lightning命令將.sql文件中的數據插入到TIDB中.
具體步驟:1 進入mydumper的安裝目錄,執行:./mydumper -h 192.168.1.XXX -P 4000 -u ROOT -p PASSWORD -t 4 -F 128 -D -l 7200 --skip-tz-utc --kill-long-queries -B DATABASE -T TABLE -v 3 -o /file_data/export/TABLENAME
命令說明: -h 192.168.1.XXX 服務器IP; -P 4000 端口; -u ROOT -p PASSWORD MySQL的用戶名和密碼 ;t 4 用4個線程同時跑數;如果文件過大,可以加 -C 表示以壓縮文件的格式生成,空間大概能壓縮70%,原來需要100G空間的,壓縮后只需要30G.批量解壓命令:
gzip -d $(find ./ -type f -name '*.gz')
mydumper命令執行完后會在 -o 所指定的文件夾下生成三個目錄,用來存放.sql的數據文件,截圖如下
記得在命令結束后手動kill掉mydumper進程.
如果MySQL和TIDB不在同一個服務器,需要把生成的文件夾傳到TIDB服務器上,如過在同一台服務器這一步可以省略.
2 修改Lightning的配置文件:
file是指定日志的存放位置,data-source-dir是mydumper生成的數據文件存放位置,連續導入多張表時記得每次重新指定位置.
3 修改tikv-importer的配置文件
注意引擎文檔存放位置空間的大小,大概為表空間的40%,如果空間不夠日志會報錯.我公司導過最大的一張表為1.7T,臨時文件最大時為1T,如果沒有這么大的空間,可以在引擎文件生成后手動刪除,每當引擎文件夠64G時會生成一個隱藏文件,如果空間足夠,我們可以不用管它,程序會在導入完成后自動刪除這些隱藏文件,如果空間不夠,我們可以自己提前手動刪除,注意,不夠64G的文件不能刪刪除,不然程序會報錯.
4 啟動importer和lightning:
啟動importer:
nohup /data/tidb-utills/bin/tikv-importer -C /data/export/tikv-importer.toml >> log.out 2>&1 &
啟動lightning:
nohup /data/tidb-utills/bin/tidb-lightning -config /data/export/sy_cd_me_buss_bidder.toml >> log1.out 2>&1 &
啟動importer和lightning執行要保證TIDB庫中已存在對應的表結構,否則會報 表不存在
log.out和log1.out是日志文件,如果命令報錯可以在日志文件中查看具體錯誤信息,命令在哪里執行日志文件就在哪里生成.
Done是正確結束的意思,如果出現Exit表示出錯,需要查看日志. 我們公司在導入一張2T的表時命令沒有報錯,日志也顯示正確結束,但用select count(*) 查詢記錄數是0,但在后面加上where id is not null 就能查出記錄數,這個問題沒有找出原因,但不影響使用.如果有人出現這種情況可以在查詢語句后加主鍵非空的判斷條件.
常遇到的報錯信息:
1 如果上次lightning命令錯誤結束,下次重新執行此命令會報 請先解決上次的錯誤. 解決辦法是刪除所有出錯的傳輸斷點,這個命令會把表結構一起刪掉,記得重新建表
./tidb-lightning-ctl --config /data/export/sy_cd_me_buss_bidder.toml --checkpoint-error-destroy=all tablename
/data/export/sy_cd_me_buss_bidder.toml 這個是lightning配置文件的位置.
2 日志中報sql語法異常,這個錯誤發生過多次,每次都是最后一個sql文件的最后一條insert語句不全導致的,解決辦法是刪除最后一條插入語句,注意:這樣並不會導致最終數據庫少一條記錄,因為 0,1,last_dump三個文件中會有別的備份.