MySQL出现复制延迟是什么原因
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表示无延时，差值越大表示 延时的秒数越多。
使用 bcc 工具观测 MySQL：1）dbstat功能：将 MySQL/PostgreSQL 的查询延迟汇总为直方图
语法：
dbstat [-h] [-v] [-p [PID [PID ...]]] [-m THRESHOLD] [-u] [-i INTERVAL] {mysql,postgres}
选项：
{mysql,postgres} # 观测哪种数据库-h, --help # 显示帮助然后退出-v, --verbose # 显示BPF程序-p [PID [PID ...]], --pid [PID [PID ...]] # 要观测的进程号，空格分隔-m THRESHOLD, --threshold THRESHOLD # 只统计查询延迟比此阈值高的-u, --microseconds # 以微秒为时间单位来显示延迟(默认单位：毫秒)-i INTERVAL, --interval INTERVAL # 打印摘要的时间间隔(单位：秒)
示例：
# 使用 sysbench 在被观测数据库上执行 select[root@liuan tools]# dbstat mysql -p `pidof mysqld` -uTracing database queries for pids 3350 slower than 0 ms...^C[14:42:26] query latency (us)
2）dbslower
功能：跟踪 MySQL/PostgreSQL 的查询时间高于阈值
语法：
dbslower [-h] [-v] [-p [PID [PID ...]]] [-x PATH] [-m THRESHOLD] {mysql,postgres}
参数：
{mysql,postgres} # 观测哪种数据库 -h, --help # 显示帮助然后退出 -v, --verbose # 显示BPF程序 -p [PID [PID ...]], --pid [PID [PID ...]] # 要观测的进程号，空格分隔 -m THRESHOLD, --threshold THRESHOLD # 只统计查询延迟比此阈值高的 -x PATH, --exe PATH # 数据库二进制文件的位置
示例：
# 使用sysbench在被观测数据库上执行update_index [root@liuan tools]# dbslower mysql -p `pidof mysqld` -m 2 Tracing database queries for pids 3350 slower than 2 ms... TIME(s) PID MS QUERY 1.765087 3350 2.996 UPDATE sbtest1 SET k=k+1 WHERE id=963 3.187147 3350 2.069 UPDATE sbtest1 SET k=k+1 WHERE id=628 5.945987 3350 2.171 UPDATE sbtest1 SET k=k+1 WHERE id=325 7.771761 3350 3.853 UPDATE sbtest1 SET k=k+1 WHERE id=5955. 使用限制
bcc 基于 eBPF 开发（需要 Linux 3.15 及更高版本）。bcc 使用的大部分内容都需要 Linux 4.1 及更高版本。
"bcc.usdt.USDTException: failed to enable probe 'query__start'; a possible cause can be that the probe requires a pid to enable" 需要 MySQL 具备 Dtrace tracepoint。
