mysql从库延时好高_MySQL 中主库跑太快，从库追不上咋整？

咱们知道生产环境中常常会遇到MySQL主从延迟问题，从原理上也能看出主库的事务提交是并发模式，而从库只有一个SQL线程负责解析，因此自己上就可能存在延迟。sql

基本原理

MySQL主从复制实际上基于二进制日志，Mysql 中主从复制时有两个很重要的日志文件：binlog(二进制日志文件)，relay log(中继日志文件)，基本原理看图片

安全

配置好了， 在主从同步过程当中， 主服务器会把更新语句写入binlog, 从服务器的IO 线程(这里要注意， 5.6.3 以前的IO线程仅有一个，5.6.3以后的有多线程去读了，速度天然也就加快了)回去读取主服务器的binlog 而且写到从服务器的Relay log 里面，而后从服务器的 的SQL thread 会一个一个执行 relay log 里面的sql ， 进行数据恢复。服务器

1. 主从同步的延迟的缘由

一个服务器开放Ｎ个连接给客户端来链接的，　这样有会有大并发的更新操做, 可是从服务器的里面读取binlog 的线程仅有一个， 当某个SQL在从服务器上执行的时间稍长 或者因为某个SQL要进行锁表就会致使，主服务器的SQL大量积压，未被同步到从服务器里。这就致使了主从不一致， 也就是主从延迟。微信

随机重放

Mysql 主库中写 binlog 的操做是顺序写的，以前咱们提到过，磁盘的顺序读写速度是很快的。一样的，从库中的 I/O 线程操做日志的速度效率也是很高的。可是别忘了，还有一个 SQL 线程来进行数据重放，而重放的过程是随机写盘的。到这里你应该就明白了吧，某一时刻 relay log 里的数据来不及重放进从库，就会产生主从延迟的状况。多线程

主库并发高

知道了从库中 SQL 线程的重放状况，对于主库并发高致使主从延迟确定就不难理解了。某一时刻，大量写请求打到主库上，意味着要不断对 binlog 进行写入，此时从库中的 SQL 线程就会目不暇接，天然会产生主从延迟。并发

锁等待

对于 SQL 单线程来讲，当遇到阻塞时就会一直等待，直到执行成功才会继续进行。若是某一时刻从库由于查询产生了锁等待的状况，此时只有当前的操做执行完成后才会进行下面的操做，同理也就产生了主从延迟的状况。线程

2. 主从同步延迟的解决办法

实际上主从同步延迟根本没有什么一招制敌的办法， 由于全部的SQL必须都要在从服务器里面执行一遍，可是主服务器若是不断的有更新操做源源不断的写入， 那么一旦有延迟产生， 那么延迟加剧的可能性就会原来越大。固然咱们能够作一些缓解的措施。日志

改变参数设置

由于主服务器要负责更新操做， 它对安全性的要求比从服务器高， 全部有些设置能够修改，好比sync_binlog=1，innodb_flush_log_at_trx_commit = 1 之类的设置，而slave则不须要这么高的数据安全，彻底能够讲sync_binlog设置为0或者关闭binlog，innodb_flushlog， innodb_flush_log_at_trx_commit 也 能够设置为0来提升sql的执行效率 这个能很大程度上提升效率。另外就是使用比主库更好的硬件设备做为slave。blog

从服务器做备份使用

把一台从服务器看成备份使用， 而不提供查询， 那边他的负载下来了， 执行relay log 里面的SQL效率天然就高了。图片

增长从服务器

这个目的仍是分散读的压力， 从而下降服务器负载。

3. 判断主从延迟的方法

MySQL提供了从服务器状态命令，能够经过 show slave status 进行查看， 好比能够看看Seconds_Behind_Master参数的值来判断，是否有发生主从延时。

其值有这么几种：

NULL - 表示io_thread或是sql_thread有任何一个发生故障，也就是该线程的Running状态是No,而非Yes.

0 - 该值为零，是咱们极为渴望看到的状况，表示主从复制状态正常

注：本文转载自【PHP自学中心】微信公众号