如何判断mysql主从延迟_【转】MySQL主从延迟如何解决

一. 如何检测主从延迟html

能够经过监控 show slave status\G

命令输出的Seconds_Behind_Master

参数值来判断，是否存在主从延时。

NULLmysql

表示io_thread或sql_thread发生故障，也就是该线程的Running状态是No。**(有故障)

0

该值为零，是咱们极为渴望看到的状况，表示主从复制良好，能够认为lag不存在。

(无延迟)

正值

表示主从已经出现延时，数字越大表示从库落后主库越多。

(有延迟)

负值sql

几乎不多见，只是听一些资深的DBA说见过，其实这是一个BUG值，该参数是不支持负值的，也就是不该该出现。

二. 主从库延迟产生的缘由缓存

在分析延迟产生缘由以前，咱们先来熟悉一下主从同步的工做原理和步骤：

步骤1： 全部数据更新都会被主库记录到主库的二进制日志。

步骤2： 与此同时从库的IO线程会从主库上读取二进制日志，写入到从库的中继日志上。

步骤3： 从库的SQL线程读取中继日志上的内容来更新从库。

究竟是什么缘由致使了主从的延迟呢？问题无非出在这三个步骤或过程当中：安全

主库对DDL和DML产生binlog，和slave的Slave_IO_Running线程从主库取日志，效率都比较高。可是，因为从库的Slave_SQL_Running是单线程做业，不能并发执行，因此当主库的TPS并发较高时，就容易产生延迟。多线程

三. 如何解决主从延迟架构

最简单的减小slave同步延时的方案就是在架构上作优化，尽可能让主库的DDL快速执行。

还有就是主库写对数据安全性较高，好比sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不须要这么高的数据安全，彻底能够将sync_binlog设置为0或者关闭binlog，innodb_flushlog也能够设置为0来提升sql的执行效率。

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

另外，mysql-5.6.3已经支持了多线程的主从复制。

注释：innodb_flush_log_at_trx_commit默认值1的意思是每一次事务提交或事务外的指令都须要把日志写入(flush)硬盘，这是很费时的。特别是使用电池供电缓存(Battery backed up cache)时。设成2对于不少运用，特别是从MyISAM表转过来的是能够的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬，因此你通常不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即便MySQL挂了也可能会丢失事务的数据。而值2只会在整个操做系统 挂了时才可能丢数据。并发