mysqlimport导入报错的排查-阿里云开发者社区

开发者社区> 数据库> 正文

mysqlimport导入报错的排查

简介: 今天有个同事问我一个mysqlimport导入的问题,看起来还是蛮奇怪的。同事在客户端导入一个文件。文件大小是2.8G,然后报错mysqlimport: Error: 2013, Lost connection to MySQL server during query 对于这个问题我的第一感觉是一台云服务器,是不是没有配置swap造成的原因,因为在之前的一次迁移中,被这类问题折磨坏了,遭遇了OOM-Killer的问题,最后发现是swap没有配置导致的。
今天有个同事问我一个mysqlimport导入的问题,看起来还是蛮奇怪的。同事在客户端导入一个文件。文件大小是2.8G,然后报错mysqlimport: Error: 2013, Lost connection to MySQL server during query
对于这个问题我的第一感觉是一台云服务器,是不是没有配置swap造成的原因,因为在之前的一次迁移中,被这类问题折磨坏了,遭遇了OOM-Killer的问题,最后发现是swap没有配置导致的。
但是同事经过确认,这是一台实体机,而且查看硬件情况,配置还不错。buffer_pool_size有50多G,swap也配置了。看来这个问题的原因初步排除了。
对于这个问题,网络上也有很多种说法。有的说是max_allowed_packets导致。查看当前的配置是1G,看起来是比导入文件小了。
不过从Oracle中的经验来看,似乎这个说法也不是完全靠得住的,如果我导入一个100G的dump,那这个参数还要配置超过100G,好像听起来也不大合理啊。而且也没见过有环境配置一个极高的值。
为此我做了几个简单的测试。
首先找了一个测试环境,max_allowed_packets为30多M.
# mysqladmin var|grep max_all
| max_allowed_packet                                | 33554432
| slave_max_allowed_packet                          | 1073741824
锁定了一个小表.
]> select count(*)from t_fund_info;
+----------+
| count(*) |
+----------+
|  1998067 |
通过查看文件大小,大概是400多M.
-rw-rw---- 1 mysql mysql  482344960 Oct 13 16:01 t_fund_info.ibd
这样就可以轻松模拟测试max_allowed_packets的场景了。
首先导出文件。
> select * from t_fund_info into outfile '/tmp/t_fund_info.txt';
Query OK, 1998067 rows affected (6.82 sec)
导出的文本文件有近300M
ll t_fund_info.txt
-rw-rw-rw- 1 mysql mysql 291963062 Oct 20 22:25 t_fund_info.txt

然后使用最简单的命令来导入:
mysqlimport  test '/tmp/t_fund_info.txt'
短暂的等待之后,成功导入。
可以看到慢日志的输出如下:
# Time: 161020 22:31:49
# User@Host: root[root] @ localhost []
# Thread_id: 4321910  Schema: test  Last_errno: 0  Killed: 0
# Query_time: 92.866443  Lock_time: 0.000074  Rows_sent: 0  Rows_examined: 0  Rows_affected: 1998067  Rows_read: 0
# Bytes_sent: 68
SET timestamp=1476973909;
LOAD DATA   INFILE '/tmp/t_fund_info.txt' INTO TABLE `t_fund_info` IGNORE 0 LINES;
原来mysqlimport会转换为load data 的形式。
然后delete,truncate,drop重建,都可以成功导入。
是哪里测试的不到位吗,我开始审视这个问题,我们可以在测试环境中模拟这个问题,以当时出问题的数据为准。然后查看同事提供的日志和截图,发现当时使用的命令是
mysqlimport  test '/tmp/t_charextra.txt' --local --delete --default-character=gbk
这个表的字符集经过确认是latin,所以就在怀疑是不是因为字符集转换造成的
ENGINE=InnoDB DEFAULT CHARSET=latin1
但是短暂的等待之后,还是可以成功导入。
# mysqlimport  test '/tmp/t_charextra.txt' --local --delete --default-character=gbk
test.t_charextra: Records: 480174  Deleted: 0  Skipped: 0  Warnings: 0
在表t_charextra存在大量数据的前提下,我们继续尝试上面的方法导入。
整个导入就会分为两部分,
SET timestamp=1476975647;
DELETE FROM t_charextra

SET timestamp=1476975748;
LOAD DATA  LOCAL INFILE '/tmp/t_charextra.txt' INTO TABLE `t_charextra` IGNORE 0 LINES;
还是能够成功导入
# mysqlimport  test '/tmp/t_charextra.txt' --local --delete --default-character=gbk
test.t_charextra: Records: 480174  Deleted: 0  Skipped: 0  Warnings: 0    
是哪里测试的不到位吗,现在唯一能够想到的就是两点,一是通过客户端调用,而是客户端和服务端的网络延迟较大。
配置了客户端用户,把导出的文本拷贝到客户端来复现问题。
> grant select,insert,delete on test.*  to testdb@10.127.133.86 identified by 'mysqlnew';
Query OK, 0 rows affected (0.02 sec)
然后使用下面的命令来尝试客户端导入。
# mysqlimport -h 10.127.xxxx -utestdb -pmysqlnew test '/U01/t_charextra.txt' --local --delete --default-character=gbk
Warning: Using unique option prefix default-character instead of default-character-set is deprecated and will be removed in a future release. Please use the full name instead.
test.t_charextra: Records: 480174  Deleted: 0  Skipped: 0  Warnings: 0
从日志看除了抛出一个警告外,一切都很正常,所以现在的重点就落在了网络上,这一点还是需要进一步确认,不过目前来看已经排除了不少原因,想必原因也快揭晓了。问题背后的原因也会在确认之后进行更多的论证和分析,敬请期待。

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
数据库
使用钉钉扫一扫加入圈子
+ 订阅

分享数据库前沿,解构实战干货,推动数据库技术变革

其他文章