用公司的实际业务记录一下数据从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三个文件中会有别的备份.