MySQL Seconds_Behind_Master的问题
Seconds_Behind_Master:
In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread.
上面解释了Seconds_Behind_Master这个值的真正含义，那么它的值到底是怎么计算出来的呢？官方解释如下:
Seconds_Behind_Master: The number of seconds that the slave SQL thread is behind processing the master binary log
也就是说是SQL thread在执行IO thread获取到的relay log的时间差。
relay log中event记录的是主库上的时间戳，SQL thread执行的时间戳是从库上的。
实际上在binlog中每个binlog events都会附上执行时的timestamp，所以在在确定Seconds_Behind_Master的值时MySQL是通过比较当前系统的时间戳与当前SQL thread正在执行的binlog event的上的时间戳做比较，这个差值就是Seconds_Behind_Master的值。
这样的话在下面这些情况这个值就会不准确：
1、主从服务器时间戳不一致；
2、在主库上执行了一个非常大的event，在这个event在主库上没执行完毕的时候，从库的SBM会显示为0，而当主库执行完毕传到从库上开始执行的时候，就会显示SBM非常巨大了；
3、主从服务器之间网络有明显的延迟；
手册上对此也进行了说明：
1、This time difference computation works even if the master and slave do not have identical clock times,
provided that the difference,computed when the slave I/O thread starts, remains constant from then on.
Any changes—including NTP updates—can lead to clock skews that can make calculation of Seconds_Behind_Master less reliable
2、It is also possible that transient values for Seconds_Behind_Master may not reflect the situation accurately.
When the slave SQL thread has caught up on I/O, Seconds_Behind_Master displays 0;
but when the slave I/O thread is still queuing up a new event, Seconds_Behind_Master may show a large value until the SQL thread finishes executing the new event.
This is especially likely when the events have old timestamps;
in such cases, if you execute SHOW SLAVE STATUS several times in a relatively short period,
you may see this value change back and forth repeatedly between 0 and a relatively large value.
MySQL的复制是推还是拉：
“拉”是指 MySQL 的备库不断的循环询问主库是否有数据更新，这种方式资源消耗多，并且效率低。
“推”是指 MySQL 的主库在自己有数据更新的时候推送这个变更给备库，这种方式只有在数据有变更的时候才会发生交互，资源消耗少。
“推”存在一个问题：如果一段时间没有数据推送，从库如何去知道是因为主库已经宕了还是真的这段时间没有数据更新？
比如说：当把主库的binlog dump进程杀掉，这时候因为网络异常或者其他原因导致Binlog dump 被kill的消息没有发送到备库。
作为监听的一方，备库一直没有收到任何变更，它会认为主库上长时间没有任何变更，导致没有变更数据推送过来。
备库就无法判断主库上对应的Binlog dump 线程到底是意外终止了，还是长时间没有任何数据变更的。
问题避免：
1、被动处理：修改主从延迟的监控方式，可以通过监控主机show master status\G的Position,和从执行show slave status\G的 Read_Master_Log_Pos（io_thread读取主库master_log_pos）和Exec_Master_Log_Pos（sql_thread执行主库的master_log_pos）进行比较得出复制是否能跟上主的状态。
2、主动预防：正确设置 --master-retry-count ， --master-connect-retry ， --slave-net-timeout 复制重试参数。
其中 master-connect-retry 和 master-retry-count 需要在 Change Master 搭建主备复制时指定，而 slave-net-timeout 是一个全局变量，可以在 MySQL 运行时在线设置。
具体的重试策略为：备库过了 slave-net-timeout 秒还没有收到主库来的数据，它就会开始第一次重试。然后每过 master-connect-retry 秒，备库会再次尝试重连主库。直到重试了 master-retry-count 次，它才会放弃重试。如果重试的过程中，连上了主库，那么它认为当前主库是好的，又会开始 slave-net-timeout 秒的等待。
slave-net-timeout 的默认值是 3600 秒， master-connect-retry 默认为 60 秒， master-retry-count 默认为 86400 次。
所以，如果主库上变更比较频繁，可以考虑将 slave-net-timeout 设置的小一点，避免主库Binlog dump 线程 终止了，无法将最新的更新推送过来。
当然 slave-net-timeout 设置的过小也有问题，这样会导致如果主库的变更确实比较少的时候，备库频繁的重新连接主库，造成资源浪费。
IO thread和SQL thread的双Yes假象的问题：
1、正常shutdown，结果状态双no
2、kill mysqld，结果状态双no
3、kill -9 mysqld，结果状态双no
In essence, this field measures the time difference in seconds between the slave SQL thread and the slave I/O thread.
上面解释了Seconds_Behind_Master这个值的真正含义，那么它的值到底是怎么计算出来的呢？官方解释如下:
Seconds_Behind_Master: The number of seconds that the slave SQL thread is behind processing the master binary log
也就是说是SQL thread在执行IO thread获取到的relay log的时间差。
relay log中event记录的是主库上的时间戳，SQL thread执行的时间戳是从库上的。
实际上在binlog中每个binlog events都会附上执行时的timestamp，所以在在确定Seconds_Behind_Master的值时MySQL是通过比较当前系统的时间戳与当前SQL thread正在执行的binlog event的上的时间戳做比较，这个差值就是Seconds_Behind_Master的值。
这样的话在下面这些情况这个值就会不准确：
1、主从服务器时间戳不一致；
2、在主库上执行了一个非常大的event，在这个event在主库上没执行完毕的时候，从库的SBM会显示为0，而当主库执行完毕传到从库上开始执行的时候，就会显示SBM非常巨大了；
3、主从服务器之间网络有明显的延迟；
手册上对此也进行了说明：
1、This time difference computation works even if the master and slave do not have identical clock times,
provided that the difference,computed when the slave I/O thread starts, remains constant from then on.
Any changes—including NTP updates—can lead to clock skews that can make calculation of Seconds_Behind_Master less reliable
2、It is also possible that transient values for Seconds_Behind_Master may not reflect the situation accurately.
When the slave SQL thread has caught up on I/O, Seconds_Behind_Master displays 0;
but when the slave I/O thread is still queuing up a new event, Seconds_Behind_Master may show a large value until the SQL thread finishes executing the new event.
This is especially likely when the events have old timestamps;
in such cases, if you execute SHOW SLAVE STATUS several times in a relatively short period,
you may see this value change back and forth repeatedly between 0 and a relatively large value.
MySQL的复制是推还是拉：
“拉”是指 MySQL 的备库不断的循环询问主库是否有数据更新，这种方式资源消耗多，并且效率低。
“推”是指 MySQL 的主库在自己有数据更新的时候推送这个变更给备库，这种方式只有在数据有变更的时候才会发生交互，资源消耗少。
“推”存在一个问题：如果一段时间没有数据推送，从库如何去知道是因为主库已经宕了还是真的这段时间没有数据更新？
比如说：当把主库的binlog dump进程杀掉，这时候因为网络异常或者其他原因导致Binlog dump 被kill的消息没有发送到备库。
作为监听的一方，备库一直没有收到任何变更，它会认为主库上长时间没有任何变更，导致没有变更数据推送过来。
备库就无法判断主库上对应的Binlog dump 线程到底是意外终止了，还是长时间没有任何数据变更的。
问题避免：
1、被动处理：修改主从延迟的监控方式，可以通过监控主机show master status\G的Position,和从执行show slave status\G的 Read_Master_Log_Pos（io_thread读取主库master_log_pos）和Exec_Master_Log_Pos（sql_thread执行主库的master_log_pos）进行比较得出复制是否能跟上主的状态。
2、主动预防：正确设置 --master-retry-count ， --master-connect-retry ， --slave-net-timeout 复制重试参数。
其中 master-connect-retry 和 master-retry-count 需要在 Change Master 搭建主备复制时指定，而 slave-net-timeout 是一个全局变量，可以在 MySQL 运行时在线设置。
具体的重试策略为：备库过了 slave-net-timeout 秒还没有收到主库来的数据，它就会开始第一次重试。然后每过 master-connect-retry 秒，备库会再次尝试重连主库。直到重试了 master-retry-count 次，它才会放弃重试。如果重试的过程中，连上了主库，那么它认为当前主库是好的，又会开始 slave-net-timeout 秒的等待。
slave-net-timeout 的默认值是 3600 秒， master-connect-retry 默认为 60 秒， master-retry-count 默认为 86400 次。
所以，如果主库上变更比较频繁，可以考虑将 slave-net-timeout 设置的小一点，避免主库Binlog dump 线程 终止了，无法将最新的更新推送过来。
当然 slave-net-timeout 设置的过小也有问题，这样会导致如果主库的变更确实比较少的时候，备库频繁的重新连接主库，造成资源浪费。
IO thread和SQL thread的双Yes假象的问题：
1、正常shutdown，结果状态双no
2、kill mysqld，结果状态双no
3、kill -9 mysqld，结果状态双no
4、reboot 服务器，结果状态双Yes
http://www.xuebuyuan.com/1896766.html
http://www.tuicool.com/articles/vEnaIf