阿里云 rds 主从延迟排查

昨天同学问我是不是数据库主从延迟有点高，可能有一分多钟，然后我就去看了rds 的监控，发现主实例上的监控显示的延迟才 1.2 秒，而且是最高 1.2 秒，感觉这样的话应该就没啥问题，然后同学跟我说他加了日志，大致的逻辑是主库数据落库以后就会发一条 mq 消息出来，然后消费者接收到以后回去从库查一下这个数据，结果发现延迟了 90 多秒才查到数据，这种情况比较可能的猜测是阿里云这个监控的逻辑可能是从库在获得第一条同步数据的时候，而不是最终同步完成，但是跟阿里云咨询了并不是，使用的就是 show slave status 结果里的 Seconds_Behind_Master 指标，那这第一种情况就否定掉了，这里其实是犯了个错误，应该去从库看这个延迟的，不过对于阿里云来说在 rds 监控是看不到从库的监控的，只能到 das，也就是阿里云的数据库自治服务可以看到，这里能看到从库的延迟监控，发现的确有这么高，这样就要考虑为啥会出现这种情况，阿里云同学反馈的是这段时间的 iops 很高，并且 cpu 也比较高，让我排查下 binlog，这里就碰到一个小问题，阿里云 rds 的线上实例我们没法在本地连接，并且密码也是在代码里加密过的，去服务器上连接一方面需要装 mysql 客户端，另一方面是怕拉取日志会有性能影响，幸好阿里云这点做的比较好，在 rds 的”备份恢复”–> “日志备份”菜单里可以找到binlog 文件， 在这里其实大致就发现了问题，因为出问题的时间段内升成 binlog 的量大大超过其他时间段，然后通过内网下载后就可以对 binlog 进行分析了，这里我们用到了 mysqlbinlog 工具，主要就是找具体是哪些写入导致这个问题，mysqlbinlog 可以在 mysql 官网下载 mysql 的压缩包，注意是压缩包，这样解压了直接用就好了，不用完整安装 mysql，一般我们需要对 binlog 进行 base64 的反编码，

1

./mysqlbinlog -vv --base64-output=decode-rows mysql-bin.xxxx | less

这样查看里面的具体信息，发现是大量的 insert 数据，再经过排查发现同一个 binlog 文件近 500M 全是同一个表的数据插入，再根据表对应的业务查找发现是有个业务逻辑会在这个时间点全量删除后在生成插入数据，后续需要进行优化