主从复制延迟的几个因素

1. 从库硬件比主库差，导致复制延迟
2. 主从复制单线程，主库写并发太大，来不及传送到从库导致延迟（更高版本的mysql可以支持多线程复制）
3. 慢SQL语句过多，网络延迟，master负载主库读写压力大，导致复制延迟（架构的前端要加buffer及缓存层slave负载）

解决办法

1. 使用多台slave来分摊读请求，再从这些slave中取一台专用的服务器只作为备份用，不进行其他任何操作,或者使用比主库更好的硬件设备作为slave

2. 可以减少延迟的参数:

   • –slave-net-timeout=seconds 单位为秒 默认设置为 3600秒 #参数含义：当slave从主数据库读取log数据失败后，等待多久重新建立连接并获取数据
   • –master-connect-retry=seconds 单位为秒 默认设置为 60秒 #参数含义：当重新建立主从连接时，如果连接建立失败，间隔多久后重试 通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟

3. 最简单的减少slave同步延时的方案就是在架构上做优化，尽量让主库的DDL快速执行

4. 还有就是主库是写，对数据安全性较高，而slave则不需要这么高的数据安全，完全可以将sync_binlog设置为0或者关闭binlog

   比如sync_binlog=1，

   write和fsync的时机就是由参数sync_binlog来进行控制的
   
   1、当sync_binlog=0的时候，表示每次提交事务都只write，不fsync
   
   2、当sync_binlog=1的时候，表示每次提交事务都执行fsync
   
   3、当sync_binlog=N的时候，表示每次提交事务都write，但积累N个事务后才fsync
   

   比如innodb_flush_log_at_trx_commit= 1

   表示每一次的事务提交是否需要把日志都写入磁盘，这是很浪费时间的，一共有三个属性值:
   0（每次写到服务缓存，一秒钟刷写一次）
   1（每次事务提交都刷写一次磁盘）
   2（每次写到os缓存，一秒钟刷写一次）
   一般情况下我们推荐设置成2，这样就算mysql的服务宕机了，卸载os缓存中的数据也会进行持久化。
   

5. innodb_flushlog也可以设置为0来提高sql的执行效率