mysql主从复制延迟问题

一.如何检测主从延迟

     可以通过监控 showslave
status\G 命令输出的seconds_behind_master 参数值来判断，是否存在主从延时。
     null -表示io_thread或sql_thread发生故障，也就是该线程的Running状态是No。（有故障）
　　0-该值为零，是我们极为渴望看到的情况，表示主从复制良好，可以认为lag不存在。（无延迟）
　　正值-表示主从已经出现延时，数字越大表示从库落后主库越多。（有延迟）
　　负值-几乎很少见，只是听一些资深的DBA说见过，其实这是一个BUG值，该参数是不支持负值的，也就是不应该出现。（BUG）

二.主从库延迟产生的原因
    


 
    在分析延迟产生原因之前，我们先来熟悉一下主从同步的工作原理和步骤：
      步骤1： 所有数据更新都会被主库记录到主库的二进制日志（变更日志）。
      步骤2： 从库的IO线程从主库上读取二进制日志，写入到从库的中继日志上。
      步骤3： 从库的SQL线程读取中继日志上的内容来更新从库。

      到底是什么原因导致了主从的延迟呢？问题无非出在这三个步骤的某个过程中，一般情况下，主库对DDL和DML产生binlog和slave的Slave_IO_Running线程从主库取日志的效率都很高，问题可能会出在从库的sql线程上，由于从库的Slave_SQL_Running是单线程作业，不能并发执行，所以当主库的TPS并发较高时，就容易产生延迟。

三.如何解决主从延迟

1. 保证主库的DDL快速执行。

2. 还有就是主库写对数据安全性较高，比如sync_binlog=1，innodb_flush_log_at_trx_commit =1之类的设置，而slave则不需要这么高的数据安全，完全可以将sync_binlog设置为0或者关闭binlog，innodb_flushlog也可以设置为0来提高sql的执行效率。

3. 选择支持多线程的mysql版本来进行主从复制，避免并发高峰时可能的延迟，mysql-5.6.3已经支持了多线程的主从复制。

4. 另外就是使用比主库更好的硬件设备作为slave。

注释：innodb_flush_log_at_trx_commit默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电池供电缓存（Batterybacked upcache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统挂了时才可能丢数据。