old post from wiznote

• 10:15 binlog服务报警，最后一条10:09
• 查看binlog日志，发现与从库延迟很小。但是观察到的binlog与主库延迟很大（逐渐增大到几十分钟），查看grafana监控后台，看到主从延迟是0。怀疑是binlog连接的从库故障，可能类似上次的刷盘故障。
• 11:00 找到DBA，想要看下从库的binlog日志列表和主库的binlog日志列表（想要对比下，看是否有延迟，但不确定是否可以对比，因为主库可能有其他数据源，从而导致和从库的binlog并不一一对应，但目前没有更好的办法）
  • DBA提供从库binlog
  • DBA本来要提供主库binlog，但是不记得主库ip，在从库执行show slave status查看
  • 意外发现输出内有事务锁异常lock wait timeout exceeded...，导致从库主从复制停止！
  • DBA重启从库，联系运维，查看为什么没有报警
• binlog日志正常，逐渐收到延迟见效的邮件。
• 11:16 binlog最后一条报警，之后正常

总结

• 发生异常的时候，在grafana后台看到的主从延迟是0（来自seconds_behind_master），这是不准确的，因为此时主从已经停止，所以seconds_behind_master没有实际意义。参看note:mysql/seconds_behind_master
• 本来自己有一个主从检测脚本，但是逻辑有问题，报警提示总是延迟1min，其实延迟了几十分钟。随后已经调整。