【转】MySQL主从延迟如何解决

一. 如何检测主从延迟

可以通过监控 show slave status\G
命令输出的Seconds_Behind_Master
参数值来判断,是否存在主从延时。
NULL

  • 表示io_thread或sql_thread发生故障,也就是该线程的Running状态是No。**(有故障)
      
    0
  • 该值为零,是我们极为渴望看到的情况,表示主从复制良好,可以认为lag不存在。
    (无延迟)
      
    正值
  • 表示主从已经出现延时,数字越大表示从库落后主库越多。
    (有延迟)

负值

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

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

【转】MySQL主从延迟如何解决_第1张图片
MySQL主从延迟如何解决

在分析延迟产生原因之前,我们先来熟悉一下主从同步的工作原理和步骤:
步骤1: 所有数据更新都会被主库记录到主库的二进制日志。
步骤2: 与此同时从库的IO线程会从主库上读取二进制日志,写入到从库的中继日志上。
步骤3: 从库的SQL线程读取中继日志上的内容来更新从库。
到底是什么原因导致了主从的延迟呢?问题无非出在这三个步骤或过程中:

主库对DDL和DML产生binlog,和slave的Slave_IO_Running线程从主库取日志,效率都比较高。但是,由于从库的Slave_SQL_Running是单线程作业,不能并发执行,所以当主库的TPS并发较高时,就容易产生延迟。

三. 如何解决主从延迟

  1. 最简单的减少slave同步延时的方案就是在架构上做优化,尽量让主库的DDL快速执行。
  2. 还有就是主库写对数据安全性较高,比如sync_binlog=1,innodb_flush_log_at_trx_commit = 1 之类的设置,而slave则不需要这么高的数据安全,完全可以将sync_binlog设置为0或者关闭binlog,innodb_flushlog也可以设置为0来提高sql的执行效率。
  3. 另外就是使用比主库更好的硬件设备作为slave。
  4. 另外,mysql-5.6.3已经支持了多线程的主从复制。

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

你可能感兴趣的:(【转】MySQL主从延迟如何解决)