MySQL：产生大量小relay log的故障一例

能力有限有误请谅解，源码版本5.7.22欢迎关注我的《深入理解MySQL主从原理 32讲 》，如下：

如果图片不能显示可查看下面链接：

https://www.jianshu.com/p/d636215d767f这个案例是朋友
@peaceful遇到的线上问题，最终线索也是他自己找到的。现象如下：实际上第一眼看这个案例我也觉得很奇怪，因为很少有人会去设置slave_net_timeout参数，同样我们也没有设置过，因此关注较少。但是
@peaceful自己找到了可能出现问题的设置就是当前从库slave_net_timeout参数设置为10。我就顺着这个线索往下分析，我们先来看看slave_net_timeout参数的功能。当前看来从库的slave_net_timeout有如下两个功能：1、设置IO线程在空闲情况下（没有Event接收的情况下）的连接超时时间。这个参数5.7.7过后是60秒，以前是3600秒，修改后需要重启主从才会生效。2、如果change master没有指定MASTER_HEARTBEAT_PERIOD的情况下会设置为sla开发云主机域名ve_net_timeout/2一般我们配置主从都没有去指定这个心跳周期，因此就是slave_net_timeout/2，它控制的是如果在主库没有Event产生的情况下，多久发送一个心跳Event给从库的IO线程，用于保持连接。但是一旦我们配置了主从（change master）这个值就定下来了，不会随着slave_net_timeout参数的更改而更改，我们可以在slave_master_info表中找到相应的设置如下：如果我们要更改这个值只能重新 change master才行。如果满足下面三个条件，将会出现案例中的故障：那么这种情况下在主库心跳Event发送给从库的IO线程之前，IO线程已经断开了。断开后IO线程会进行重连，每次重连将会生成新的relay log，但是这些relay log由于延迟问题不能清理就出现了案例中的情况。下面是官方文档中关于这部分说明：有了理论基础就很好了模拟了，但是延迟这一点不太好模拟，因此我模拟的时候关闭了从库的SQL线程来模拟积压的情况。提前配置好主从，查看当前的心跳周期和slave_net_timeout参数如下：stop slave sql_thread;可以看到这里实际上已经有一个警告了。这样才会让slave_net_timeout参数生效大概每10秒会生成一个relay log文件如下：大概每10秒主库的日志会输出如下日志：这个日志就和案例中的一模一样了。知道原因后解决也就很简单了我们只需设置slave_net_timeout参数为MASTER_HEARTBEAT_PERIOD的2倍就可以了，设置后重启主从即可。这里我们将通过简单的源码调用分析来看看到底slave_net_timeout参数和MASTER_HEARTBEAT_PERIOD对主从的影响。从库IO线程启动时候会通过参数slave_net_timeout设置超时：而在建立和主库的连接时候会使用这个值因此我们也看到了slave_net_timeout参数只有在IO线程重启的时候才会生效在每次使用从库change master时候会设置这个值如下，默认为slave_net_timeout/2：因此我们看到只有change master才会重新设置这个值，重启主从是不会重新设置的。每次IO线程启动时候会将这个值传递给主库的DUMP线程，方式应该是通过构建语句‘SET
@master_heartbeat_period’来完成的。如下：主库启动DUMP线程的时候会通过搜索的方式找到这个值如下这里主要是通过一个超时等待来完成，如下：根据UUID进行比对如下：这里我们看到了案例中的日志。最后给出一张来自我《MySQL主从原理32讲》第17节中DUMP线程的流程图如下：
在图中可以看到心跳Event发送的位置。作者微信：
gp_22389860

相关推荐: ​mysql多源复制跳过错误处理方法

mysql多源复制跳过错误处理方法：第一种方法：先停止所有的channel，再执行 sql_slave_skip_counter，接着开启报错的channel，最后开启所有的channel。第二种方法：也可以直接停掉错误的channel，再sql_slave_…