监控方法
方法一： 有没有延时
Seconds_Behind_Master: 0
方法二：
主库：
mysql> show master status ;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000004 | 151847 | | | |
+------------------+----------+--------------+------------------+-------------------+
1 row in set (0.00 sec)
从库：
[root@db01 data]# mysql -S /tmp/mysql3308.sock -uroot -p123 -e "show slave status \G"|grep "Master_Log"
已经拿到的主库日志量(master.info)：
Master_Log_File: mysql-bin.000004
Read_Master_Log_Pos: 151847
已经执行的主库日质量(relay-log.info):
Relay_Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 141847
计算主从复制延时日志量。
主库
（1） binlog记录不及时。
mysql> select @@sync_binlog;
+---------------+
| @@sync_binlog |
+---------------+
| 1 |
+---------------+
参数说明：
1 ： 每次事务提交都立即刷新binlog到磁盘。
0 ： 由操作系统决定，什么刷新磁盘。
（2） DUMP线程串行工作。
大事务、并发事务高、DDL
解决办法：
5.6版本加入GTID复制模式，但手工配置。DUMP在传输日志时可以并发。
5.7版本GTID做了增强，不手工开启也自动维护匿名的GTID信息。
从库方面
IO线程：
从库IO比较慢。relay 落地慢。可以将realy放到 SSD
SQL 线程： 串行回放。
主库可以并行事务，从库SQL线程串行回放。
所以：并发事务高、大事务、DDL
解决方法：
5.6 版本： 开启GTID后，可以多SQL线程，只能针对不同的库的事务进行并行SQL恢复。
5.7 版本： 做了增强，基于逻辑时钟的并行回放。MTS。
5.7 的从库并发配置方法。
gtid_mode=ON
enforce_gtid_consistency=ON
log_slave_updates=ON
slave-parallel-type=LOGICAL_CLOCK
slave-parallel-workers=16
master_info_repository=TABLE
relay_log_info_repository=TABLE
已经执行的主库日质量(relay-log.info): 判断回放有没有延时
Relay_Master_Log_File: mysql-bin.000004
Exec_Master_Log_Pos: 141847