本文共 6009 字，大约阅读时间需要 20 分钟。
最近在mysqldump时，遭遇mysqldump: Error 2013错误。以为是常见的参数设置有问题，调整之后，也没有任何成效。原来发生了OOM，以下是其具体描述。
环境# more /etc/redhat-release CentOS Linux release 7.4.1708 (Core) # mysql -V ##PXC 5.7mysql 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.sqlEnter 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/messageApr 26 15:13:10 zcd kernel: Out of memory: Kill process 10274 (firewalld) score 5 or sacrifice childApr 26 15:13:10 zcd kernel: Killed process 10274 (firewalld) total-vm:333984kB, anon-rss:21980kB, file-rss:44kB, shmem-rss:0kBApr 26 15:13:10 zcd systemd: firewalld.service: main process exited, code=killed, status=9/KILLApr 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>&1Apr 26 15:13:10 zcd mysqld_safe: 2018-04-26T07:13:10.742581Z mysqld_safe Number of processes running now: 0Apr 26 15:13:10 zcd mysqld_safe: 2018-04-26T07:13:10.831232Z mysqld_safe WSREP: not restarting wsrep node automaticallyApr 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 st1 1 0 625288 31836 1347284 0 0 19840 372 3181 3394 9 3 42 46 00 1 0 586820 31844 1365304 0 0 19840 60 2385 3264 7 3 46 44 00 1 0 515076 31956 1400024 0 0 19312 564 2681 3327 7 4 43 46 00 1 0 478708 31964 1417948 0 0 20368 24 3057 3301 8 4 43 46 00 1 0 400960 31964 1452688 0 0 19840 0 2213 3278 7 3 44 47 00 1 0 364868 31964 1468268 0 0 19840 24648 3053 3500 7 4 40 50 00 2 0 324640 31976 1488112 0 0 4544 43656 1079 1688 2 2 14 83 00 1 0 286768 32116 1505272 0 0 19840 760 3412 3877 7 5 25 64 00 1 0 248916 32132 1520528 0 0 19840 36 4065 5746 13 4 43 41 00 1 0 127684 30816 1523336 0 0 24064 28 2960 3367 31 5 33 30 00 2 0 118504 7912 1451700 0 0 7760 85816 1290 1439 7 2 11 80 01 1 0 103628 7912 1462920 0 0 10292 48940 1381 1544 12 2 6 80 04 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 st1 1 0 840868 7156 1202532 0 0 19840 0 2890 3263 8 4 42 46 00 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 02 0 40 150880 2460 1381652 0 40 44468 24708 3669 4236 42 7 50 2 02 0 132 141280 2448 1355680 0 92 37668 24716 4748 5562 68 6 22 4 01 1 196 105804 2296 1283964 0 0 20992 8720 4494 5943 34 5 14 47 01 0 252 146424 2204 1220072 0 56 26596 844 5927 7514 51 7 22 19 02 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 00 1 2836 149376 468 828172 0 180 53712 220 2499 2212 25 7 48 20 00 1 3312 149976 568 781156 0 476 46224 29220 3385 3351 22 8 38 32 00 1 3696 150440 692 743464 0 384 37484 62616 3310 3924 17 7 34 42 00 0 4188 150300 688 699140 0 492 44896 33304 3010 3352 21 8 41 31 00 0 4576 142428 660 653872 0 388 55204 58748 2487 2050 26 8 49 17 0--查看交换分区使用情况# cat /proc/meminfo|grep -i swapSwapCached: 375664 kB -- Author : LeshamiSwapTotal: 4194300 kB -- Blog : https://blog.csdn.net/leshamiSwapFree: 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
一个数据包或任何生成/中间字符串的最大大小，设置过小时发出“信息包过大”错误，并关闭连接