主从复制延时原因
Master负载过高、Slave负载过高、网络延迟、机器性能太低、MySQL配置不合理，大事务导致的延迟，slave中有大型query语句产生了锁等待
关于大事务：binlog的写入时机是在commit的时候，redo的写入时机是在事务执行阶段就开始，MySQL是基于binlog复制的，如果有一个非常大的事务，如果需要1个小时，那么master在1小时候后才会生成binlog，而此时，slave就比master慢了至少1个小时，还不算是binlog传输时间
主从同步延时查询方法
show slave status 命令输出的Seconds_Behind_Master参数的值来判断：
NULL，表示io_thread或是sql_thread有任何一个发生故障；
0， 该值为零，表示主从复制良好；
正值，表示主从已经出现延时，数字越大表示从库延迟越严重
数据丢失隐患解决
从MySQL5.5开始，MySQL已经支持半同步复制了，半同步复制介于异步复制和同步复制之间半同步复制，也叫 semi-sync 复制，指的就是主库写入 binlog 日志之后，就会将强制此时立即将数据同步到从库，从库将日志写入自己本地的 relay log 之后，接着会返回一个 ack 给主库，主库接收到至少一个从库的 ack 之后才会认为写操作完成了。
同步延时解决（show status：Seconds_Behind_Master）
1.硬件层面：硬盘采用SSD替代sata,主从要在一个交换机下并且保证带宽
2.从文件系统本身进行优化：可以通过设置文件系统的mount属性，阻止操作系统写atime信息。
3.加入memcache或者redis的cache层，特殊业务查询时候优先从缓存中进行查询，降低从库数据库服务的压力。
4.并行复制，mysql 5.7.19 + 版本支持并行复制，指的是从库开启多个线程，并行读取 relay log 中不同库的日志，然后并行重放不同库的日志，这是库级别的并行。如果说某个库的写入并发就是特别高，单库写并发达到了 2000/s，并行复制还是没意义。
5.直接禁用slave端的binlog
6.slave端，如果使用的存储引擎是innodb，innodb_flush_log_at_trx_commit =2
7.分库，将一个主库拆分为多个主库，每个主库的写并发就减少了几倍，此时主从延迟可以忽略不计。
8.如果说大事务对于binlog的产生有极大的影响，那么我们认为定义小事务，大事务不允许执行，有大事务的监控，可以基于时间，可以基于数据量，监控到不符合规范的trx自动kill