PXC 5.7 mysqldump: Error 2013
PXC 5.7 mysqldump: Error 2013
Leshami
发布于 2018-07-31 17:19:11
发布于 2018-07-31 17:19:11
最近在mysqldump时，遭遇mysqldump: Error 2013错误。以为是常见的参数设置有问题，调整之后，也没有任何成效。原来发生了OOM，以下是其具体描述。
一、故障现象
环境
# more /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
# mysql -V ##PXC 5.7
mysql Ver 14.14 Distrib 5.7.20-18, for Linux (x86_64) using 6.2
# mysqldump -hlocalhost -uroot -p --port=33006 --default-character-set=utf8 -F -R -E --triggers -e \
> --single-transaction --all-databases >/tmp/alldb.sql
Enter password:
mysqldump: Error 2013: Lost connection to MySQL server during query when dumping table `tel_send_log` at row: 390486
表并不是很大，也就200w左右的数据行。二、故障分析
起初以为是相关变量设置有问题，因此调整相关参数
mysql > set global connect_timeout=1800;
mysql > set global net_read_timeout=1800;
mysql > set global net_write_timeout=1800;
mysql > set global max_allowed_packet=1024*1024*1024;
mysql > set global net_buffer_length=1024*1024;
之后再次导出，问题依旧，而且报错之后，mysqld就直接挂了
查看mysqld的error log也未得到相关报错的具体信息，还以为是版本太新遭遇Bug呢
后来加上一个选项--skip-extended-insert(这个是不启用mysql 生成insert包含多values)也不行
换到另一个节点后，导出却是正常的。
于是打开报错系统日志message一看，竟然out of memory
# tail -fn 50 /var/log/message
Apr 26 15:13:10 zcd kernel: Out of memory: Kill process 10274 (firewalld) score 5 or sacrifice child
Apr 26 15:13:10 zcd kernel: Killed process 10274 (firewalld) total-vm:333984kB, anon-rss:21980kB, file-rss:44kB, shmem-rss:0kB
Apr 26 15:13:10 zcd systemd: firewalld.service: main process exited, code=killed, status=9/KILL
Apr 26 15:13:10 zcd mysqld_safe: /usr/bin/mysqld_safe: line 220: 9658 Killed
nohup /usr/sbin/mysqld --basedir=/usr --datadir=/u02/pxcdata --plugin-dir=/usr/lib64/mysql/plugin --user=mysql
--wsrep-provider=/usr/lib64/galera3/libgalera_smm.so --log-error=/var/log/mysqld.log
--pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock --port=33006
--wsrep_start_position=e12b32d1-06f1-11e8-b907-d7b0846b449d:68722 < /dev/null > /dev/null 2>&1
Apr 26 15:13:10 zcd mysqld_safe: 2018-04-26T07:13:10.742581Z mysqld_safe Number of processes running now: 0
Apr 26 15:13:10 zcd mysqld_safe: 2018-04-26T07:13:10.831232Z mysqld_safe WSREP: not restarting wsrep node automatically
Apr 26 15:13:10 zcd mysqld_safe: 2018-04-26T07:13:10.835441Z mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
于是重启mysql，然后再次导出，观察内存占用情况，如下，可以看到free列值不断减少
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 1 0 625288 31836 1347284 0 0 19840 372 3181 3394 9 3 42 46 0
0 1 0 586820 31844 1365304 0 0 19840 60 2385 3264 7 3 46 44 0
0 1 0 515076 31956 1400024 0 0 19312 564 2681 3327 7 4 43 46 0
0 1 0 478708 31964 1417948 0 0 20368 24 3057 3301 8 4 43 46 0
0 1 0 400960 31964 1452688 0 0 19840 0 2213 3278 7 3 44 47 0
0 1 0 364868 31964 1468268 0 0 19840 24648 3053 3500 7 4 40 50 0
0 2 0 324640 31976 1488112 0 0 4544 43656 1079 1688 2 2 14 83 0
0 1 0 286768 32116 1505272 0 0 19840 760 3412 3877 7 5 25 64 0
0 1 0 248916 32132 1520528 0 0 19840 36 4065 5746 13 4 43 41 0
0 1 0 127684 30816 1523336 0 0 24064 28 2960 3367 31 5 33 30 0
0 2 0 118504 7912 1451700 0 0 7760 85816 1290 1439 7 2 11 80 0
1 1 0 103628 7912 1462920 0 0 10292 48940 1381 1544 12 2 6 80 0
4 0 0 118168 4796 1351416 0 0 45280 36 4926 5351 56 9 28 7 0
###三、故障解决
由于当前服务器内存较小，也没有配置交换分区，因此考虑为其添加交换分区。
再次导出观察内存的使用情况。
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 1 0 840868 7156 1202532 0 0 19840 0 2890 3263 8 4 42 46 0
0 1 0 796156 7156 1220716 0 0 19840 0 2420 3354 8 4 42 46 0
...............................................
0 0 0 140568 2704 1436180 0 0 41776 72 3076 2674 42 6 34 18 0
2 0 40 150880 2460 1381652 0 40 44468 24708 3669 4236 42 7 50 2 0
2 0 132 141280 2448 1355680 0 92 37668 24716 4748 5562 68 6 22 4 0
1 1 196 105804 2296 1283964 0 0 20992 8720 4494 5943 34 5 14 47 0
1 0 252 146424 2204 1220072 0 56 26596 844 5927 7514 51 7 22 19 0
2 0 468 148704 2076 1177068 0 216 41748 584 4132 4234 61 7 25 8 0
......................可以看到swpd的值不断的增加，si的值也不断增加............
0 1 2656 140876 544 888484 0 444 26844 19424 2286 2654 12 5 22 62 0
0 1 2836 149376 468 828172 0 180 53712 220 2499 2212 25 7 48 20 0
0 1 3312 149976 568 781156 0 476 46224 29220 3385 3351 22 8 38 32 0
0 1 3696 150440 692 743464 0 384 37484 62616 3310 3924 17 7 34 42 0
0 0 4188 150300 688 699140 0 492 44896 33304 3010 3352 21 8 41 31 0
0 0 4576 142428 660 653872 0 388 55204 58748 2487 2050 26 8 49 17 0
--查看交换分区使用情况
# cat /proc/meminfo|grep -i swap
SwapCached: 375664 kB -- Author : Leshami
SwapTotal: 4194300 kB -- Blog : https://blog.csdn.net/leshami
SwapFree: 2624524 kB
--至此故障解决。四、几个参数描述
connect_timeout 连接响应超时时间。服务器端在这个时间内如未连接成功，则会返回连接失败。
wait_timeout 连接空闲超时时间。与服务器端无交互状态的连接，直到被服务器端强制关闭而等待的时间。 可以认为是服务器端连接空闲的时间，空闲超过这个时间将自动关闭。
interactive_timeout 连接空闲超时时间。与服务器端无交互状态的连接，直到被服务器端强制关闭而等待的时间。
interactive_timeout和wait_timeoutu两者差异
interactive_timeout针对交互式连接（比如通过mysql客户端连接数据库）， wait_timeout针对非交互式连接（比如一般在PHP中使用PDO连接数据库，当然你可以设置CLIENT_INTERACTIVE选项来改变）。 所谓的交互式连接，即在mysql_real_connect()函数中使用了CLIENT_INTERACTIVE选项。
net_read_timeout 数据读取超时时间。在终止读之前，从一个连接获得数据而等待的时间秒数； 当服务正在从客户端读取数据时，net_read_timeout控制何时超时。 即客户端执行数据读取，等待多少秒仍未执行成功时自动断开连接。
net_write_timeout 数据库写超时时间。和net_read_timeout意义类似，在终止写之前，等待多少秒把block写到连接； 当服务正在写数据到客户端时，net_write_timeout控制何时超时。
slave-net-timeout 从库延后同步的时间，当slave认为连接master的连接有问题时，就等待N秒，然后断开连接， 重新连接masterslave-net-timeout在主从同步时从库上起作用；
connect_timeout：在获取连接阶段起作用； interactive_timeout和wait_timeout：在连接空闲阶段起作用； net_read_timeout和net_write_timeout：则是在连接执行时起作用。
max_allowed_packet 一个数据包或任何生成/中间字符串的最大大小，设置过小时发出“信息包过大”错误，并关闭连接
本文参与 腾讯云自媒体分享计划，分享自作者个人站点/博客。
原始发表：2018年04月27日，如有侵权请联系 cloudcommunity@tencent.com 删除
评论
登录后参与评论
推荐阅读
目录
相关产品与服务
云数据库 MySQL
腾讯云数据库 MySQL（TencentDB for MySQL）为用户提供安全可靠，性能卓越、易于维护的企业级云数据库服务。其具备6大企业级特性，包括企业级定制内核、企业级高可用、企业级高可靠、企业级安全、企业级扩展以及企业级智能运维。通过使用腾讯云数据库 MySQL，可实现分钟级别的数据库部署、弹性扩展以及全自动化的运维管理，不仅经济实惠，而且稳定可靠，易于运维。