描述

在部署某一系统需要迁移mysql数据，转为sql大概100G左右（数据文件400G左右）。

现通过mysqldump导出为sql后远端执行source导入。

在导入过程中出现 ERROR 2013 Lost connection to Mysql server during query 报错。

解决流程

1、并未在网上找到行之有效的解决办法。

2、查阅官方文档。

官方文档将 error 2003 与 error 2013 错误放在一起说明

但之后并未针对 error 2013 提供有效的解决方案。

3、猜测

正常mysql断开连接会存在确切的返回信息，譬如

客户端超时了，服务器端会先返回客户端信息告诉客户端已超时，后断开连接。

而 error 2013 客户端并未接收到任何服务器端回复。

故判定此时 error 2013 极大程度上是网络被切断而导致的。

4、复现错误

复现 error 2013 错误

通过某一客户端连接mysql（称之为客户端A）

另外登录 mysql 执行

show processlist;

找到A客户端连接的进程 id

执行（id 为确切的连接进程id数值）

kill id;

A客户端报错 error 2013

复现成功。

5、二次猜测

经测试，系统其余表导入正常，无报错，大小有 <1M – 10G 不等。

唯独只有一张 FQDN 表导入报错。

FQDN表与其它表最大区别在于导入过程中有部分事务提交时间长达10-20分钟。

考虑到部署单位使用的为内网中云数据库、且对数据保密性要求极高。

大胆猜测：防火墙对空置连接设置了超时时间，在source导入数据提交过程中长达10-20分钟无网络数据传输，导致防火墙切断连接。

猜测防火墙超时断连策略为（ip + time ）而不是（connection + time），因此在xshell连接时挂着mysql命令行并不会被断开而报error 2013。

存在疑问：source命令是可以断开后自动重连的，但此处表现情况为 source重连失败或为进行重连。此原因还未找到，待下一步探究。

6、再次测试

从网络被切断以及进程被kill层级出发。

首先测试source命令的断开重连情况。经测试发现：在事务提交阶段，也就是show processlist后事务若处于sleep状态，且下一步操作非查询类操作（譬如select、show等），这一步操作无法触发重连。

而若是下一步为查询操作则可触发重连。

此现象符合防火墙超时断连猜想。

在测试空置连接的超时状况时发现一个问题。

有关2013错误与2006错误的关系。

当时测试mysql服务器端设置的wait_timeout报错的具体信息时，使用python import MysqlDB进行连接，然后sleep等待另一方kill或者超时后，报错为ERROR 2006，而若是terminal 的mysql命令行等待kill或超时后，报错为 ERROR 2013。

猜测可能与交互式连接（terminal登录）/非交互式连接（mysqldb连接）的区别有关。

更新时间： 2019.03.14