我有一个主服务器和几个从服务器复制单个数据库。 我在SLES 11中的MySQL 5.0中使用。在容错testing期间，我发现当从站的networking连接中断（电缆未插入）然后恢复时，复制挂起。 它显示没有错误，从服务器似乎正在运行，但Read_Master_Log_Pos和Exec_Master_Log_Pos值与主服务器上的日志位置不匹配。
Slave_IO_State是“等待主机发送事件”。
Slave_IO_Running和Slave_SQL_Running值都是“是”。
Master_Log_File和Relay_Master_Log_File匹配。
如果我停止并启动从属服务器或重新启动mysql守护进程，复制将再次开始。
任何想法，我可以做什么呢？
当一个MySQL从机连接到主机时，它会请求一个二进制日志stream，并且主机自动发送binlog事件，除非您使用半同步复制，否则从机不需要确认。
除了由TCP堆栈处理的低级别确认之外，从设备不产生任何stream量。 连接中断（在堆栈的各个层次上，不限于拔下的电缆）可能会导致连接在多种方式中断，包括由于超时导致主机的TCP堆栈断开连接或ICMP不可达消息或状态防火墙在机器之间“遗忘”TCP会话，并静静地丢弃随后的数据包，从机静静地坐着，等待下一个数据包从主机出来。
这里的解决scheme是全局variablesslave_net_timeout 。
在从设备认为连接断开之前等待来自主设备的更多数据的秒数，放弃读取并尝试重新连接。
这是在从站上configuration的。 当从机连接到主机时，在请求二进制日志stream之前，它要求主机发送心跳事件，这些事件被格式化为二进制日志事件，并且像主机二进制日志中的下一个事件一样stream式传输，但实际上并没有增加binlog位置计数器。 它们在正常操作中基本上是零开销的，因为除非主设备没有为从设备的slave_net_timeout设置的一半产生新的二进制日志事件，否则它们不会被发送（默认;或者在CHANGE MASTER TO期间可以configuration的另一个值），所以心跳事件实际上只是在交通很轻的时候才会产生……所以，只要将这个值设置为几秒钟，就没有任何实际的危害。
如果从服务器看到超时过期，它将closures连接并重新连接到主服务器。
在主机没有意识到从机已经离开的远程机会上，当从机重新连接时，主机会closures原来的连接，因为一个MySQL主机在接受一个新的从机连接时会检查另一个从机是否有相同的连接server_id已连接，如果是，则删除原始连接。 顺便说一句，为什么两个configuration了相同server_id （不支持的configuration）的从站无法成功保持连接到同一个主服务器的原因 – 只要其中一个连接，就会导致另一个服务器被碰撞，一个循环随着每个奴隶迫使另一个人的连接被丢弃。
在my.cnf中将此variables设置为适当的低值并重新启动从站应该解决这个问题。