从库slave的数值变得越来越大原因。
Seconds_Behind_Master理论上应该为0，虽然该参数不能准确判断主从间的数据同步，但可以通过该参数来简单监控/判断主从库间的同步状况。而新搭建MHA架构中Seconds_Behind_Master越来越大，这显然就不正常了。

延迟我们可将其分为两类：
1、第一类（成服务器有较高的负载）
这一类延迟情况可能造成服务器有较高的负载，可能是CPU/IO的负载。因为从库在实际执行Event，如果我们服务器的负载比较高应该考虑这几种情况。

大事务造成的延迟，其延迟不会从0开始增加，而是直接从主库执行了多久开始。比如主库执行这个事务花费的20秒，那么延迟就会从20开始，可以自己细心观察一下很容易看到。这是因为Query Event中没有准确的执行时间。

大表DDL造成的延迟，其延迟会从0开始增加，因为Query Event记录了准确的执行时间。

表没有合理的使用主键或者唯一键造成的延迟。这种情况不要以为设置slave_rows_search_algorithms参数为 INDEX_SCAN,HASH_SCAN就可以完全解决问题。

由于参数sync_relay_log，sync_master_info，sync_relay_log_info不合理导致，特别是sync_relay_log会极大的影响从库的性能。因为sync_relay_log设置为1会导致大量relay log刷盘操作。

是否从库开启了记录binary log功能即log_slave_updates参数开启，如果不是必要可以关闭掉。这种情况我遇到很多次了。

2、第二类（不会造成服务器有较高的负载）

这一类延迟情况往往不会造成服务器有较高的负载。它们要么没有实际的执行Event，要么就是做了特殊的操作造成的。

长期未提交的事务可能造成延迟瞬间增加，因为GTID_EVENT和XID_EVENT是提交时间其他Event是命令发起的时间。
Innodb层的行锁造成的延迟，这种是在从库有修改操作并且和SQL线程修改的数据有冲突的情况下造成的。
MySQL层的MDL LOCK造成的延迟，这种情况可能是由于SQL线程执行某些DDL操作但是从库上做了锁表操作造成。
MTS中不合理的设置参数slave_checkpoint_period参数导致。

其次
1、Innodb层的行锁造成的延迟
2、MySQL层的MDL LOCK造成的延迟

同时如果出现了延迟，我们首先查看从库是否有负载，根据是否有负载进行区别对待，注意这里的负载一定要使用top -H查看io/sql/worker线程的负载。我曾不止一次的遇到朋友问我延迟问题，当我问他负载如何的时候他告诉我负载不高啊整体负载也就不到2，这里我们应该注意的是对于一个线程只能使用到一个CPU核，虽然整体负载不到2但是可能io/sql/worker线程已经跑满了，实际上负载已经很高了

我们查看CPU负载应该使用top -H去查看，查看io负载可以使用iotop，iostat等工具。我需要强调一下看MySQL负载的时候我们必须用线程的眼光去看