13518219792
主从复制延迟的监测，我以前的做法是通过比较show slave statusG中的两个变量的差值（Read_Master_Log_Pos，Exec_Master_Log_Pos），将差值设置为一个自己认为合理的范围，Seconds_Behind_Master 没有适用过，今天做一次解析:
创新互联公司从2013年成立，是专业互联网技术服务公司，拥有项目成都网站设计、成都网站制作网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元宜秀做网站,已为上家服务,为宜秀各地企业和个人服务,联系电话:18980820575
Seconds_Behind_Master 是通过比较 SQL THREAD 接受 events事件的时间戳（timestamp） 与IO THREAD 执行事件 events时间戳的差值--秒数来确定slave 落后于master多少。如果主从机器的时间不同，该时间的计算也是不会受影响的（如果时间发生异常，则这个秒数的就不怎么可靠啦）
如果slave SQL thread 或者 slave I/O thread 或者没有连接到master，那么该变量的值为NULL.
0：表示master slave 复制没有延迟（大部分情况下是这个样子）。
正值：表示slave落后于master的秒数。
在网络很快的情况下，I/O thread 能够很快的从master上获取binlog到slave的 relay-log。这种情况下， seconds_behind_master的值能真正代表slave落后于master的秒数。在网络很差的情况下，I/O thread 同步很慢，slave收到的二进制日志信息，SQL THREAD能够很快的执行。这个时候 seconds_behind_master 是0，这种情况下 slave落后于master很多。
为了排除网络的干扰，我们可以参考percona 的工具 pt-heartbeat.
该工具可以计算出MySQL复制或者是PostgreSQL,它可以更新master或者监控复制。它还可以从my.cnf 读取配置。它借助timestmp的比较实现的，首先需要保证主从服务器时间必须要保持一致，通过与相同的一个NTP server同步时钟。它需要在主库上创建一个heartbeat的表，里面的时间戳ts就是当前的时间戳 now()，该结构也会被复制到从库上。表建好以后，会在主库上以后台进程的模式去执行一行更新操作的命令，定期去向表中的插入数据，这 个周期默认为1 秒，同时从库也会在后台执行一个监控命令，与主库保持一致的周期+0.5S（默认0.5S延迟检查）去比较，复制过来记录的ts值与主库上的同一条ts值，差值为0表示无延时，差值越大表示 延时的秒数越多。
1.网络的延迟
由于mysql主从复制是基于binlog的一种异步复制，通过网络传送binlog文件，理所当然网络延迟是主从不同步的绝大多数的原因，特别是跨机房的数据同步出现这种几率非常的大，所以做读写分离，注意从业务层进行前期设计。
2.主从两台机器的负载不一致
由于mysql主从复制是主数据库上面启动1个io线程，而从上面启动1个sql线程和1个io线程，当中任何一台机器的负载很高，忙不过来，导致其中的任何一个线程出现资源不足，都将出现主从不一致的情况。
3.max_allowed_packet设置不一致
主数据库上面设置的max_allowed_packet比从数据库大，当一个大的sql语句，能在主数据库上面执行完毕，从数据库上面设置过小，无法执行，导致的主从不一致。
4.key自增键开始的键值跟自增步长设置不一致引起的主从不一致。
怎样解决MySQL数据库主从复制延迟的问题
可以通过监控show slave status\G命令输出的Seconds_Behind_Master参数的值来判断，是否有发生主从延时。
其值有这么几种：
NULL - 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No,而非Yes.
0 - 该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。
正值 - 表示主从已经出现延时，数字越大表示从库落后主库越多。
负值 - 几乎很少见，只是听一些资深的DBA说见过，其实，这是一个BUG值，该参数是不支持负值的，也就是不应该出现。
