首先说明下几个概念：

1. slave_net_timeout，这个变量控制备库 IO 线程的连接超时，如果IO线程在指定时间内没有从主库收到数据的话，就断开重连，默认值是3600秒；
2. GTID 的 auto_position 协议，正是因为有了 GTID，才可以在 chang master 时不指定binlog坐标（filename, pos），但是主库dump线程在发给备库event的时候，还是需要从某个坐标开始的，只是这个过程通过 GTID 能自动搜出来罢了，关于如何找到要发送的第一个 binlog 可以看下之前的月报，找到后就需要从这个 binlog 开头开始扫描，找到第一个备库没有 GTID，然后开始发送。

IO 线程重连会导致另外一个问题，我们知道一个主库是可以拖多个备库的，但是对每个备库只能有一个连接，如果已经连上来的备库再发一个 dump 请求的话，主库就会把当前备库老的 IO 连接置为 killed，具体函数是 sql/rpl_master.cc 中的 kill_zombie_dump_threads，但这个 kill 只是置了标志位，还需要老的 dump 线程自己判断，然后退出。dump 线程 killed 状态检测只在切换 binlog 和空闲的时候，如果这个时候老的 dump 线程还在扫 binlog，即使已经是killed了也不会退出。而同时新的 dump 线程依然要从头扫 binlog，重复上面的过程，导致备库 IO 又超时重连，因此在主库上show processlist的话，会看到 dump 线程慢慢堆积起来。

如果在备库上 show slave status 的的话，会看到 IO 线程接收的 binlog 位点一直不更新，就像 hang 住了一样。

有了这个 patch 后，主库 dump 线程还是需要时间扫描binlog，备库的 IO 线程看起来依然像 hang 住一样，但是已经不会超时重连，主库的dump 线程也不会堆积。