MYSQL主从延迟问题原因及解决

彻底解决的策略
方案1. 业务妥协,从主库读

方案2. 同步写入缓存redis,修改完成5分钟内都直接从redis读。

其他让延迟变好的策略
1.并行复制 2.降低并发,增加机器

思维导图


1.常见的主从架构

随着日益增长的访问量,单台数据库的能力已经捉襟见肘。因此采用主库写数据,从库读数据这种将读写分离开的主从架构便随之衍生了出来。

1. 一主一从
2. 一主多从
一主一从和一主多从是最常见的主从架构,实施起来简单并且有效,不仅可以实现高可用,还能读写分离,进而提升集群的并发能力。
3. 多主一从
4. 双主复制
5. 级联复制

2.主从同步原理

想要了解主从同步原理,首先得记住两个很重要的日志文件

binlog(二进制日志文件)

relay log(中继日志文件)


主从同步过程

– 从库生成两个线程,一个I/O线程,一个SQL线程;
– i/o线程去请求主库 的binlog,并将得到的binlog日志写到relay log(中继日志) 文件中;
– 主库会生成一个 log dump 线程,用来给从库 i/o线程传binlog
– SQL 线程,会读取relay log文件中的日志,并解析成具体操作,来实现主从的操作一致,而最终数据一致;

3. 如何判断主从是否延时

通过监控 show slave status 命令输出的Seconds_Behind_Master参数的值来判断:

NULL,表示io_thread或是sql_thread有任何一个发生故障;

0,该值为零,表示主从复制良好;

正值,表示主从已经出现延时,数字越大表示从库延迟越严重。

4. 主从延迟原因

### 随机重放

MySQL的主从复制都是单线程的操作,主库对所有DDL和DML产生的日志写进binlog,由于binlog是顺序写,所以效率很高。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的,不是顺序的,成本高很多。所以SQL Thread线程的速度赶不上主库学binlog的速度,就会产生主从延迟

### 锁等待

另一方面,由于SQL Thread也是单线程的,当主库的并发较高时,产生的DML数量超过slave的SQL Thread所能处理的速度,或者当slave中有大型query语句产生了锁等待那么延时就产生了。

5. 主从延迟解决办法

### 并行复制

既然 SQL 单线程进行重放时速度有限,那么能不能采用多线程的方式来进行重放呢?MySQL 5.6 版本后,提供了一种并行复制的方式,通过将 SQL 线程转换为多个 work 线程来进行重放,这样就解决了主从延迟的问题

### 降低并发

如果你理解了随机重放这个导致主从延迟的原因,那么就比较好理解了,控制主库写入的速度,主从延迟发生的概率自然就小了。

### 读主库

如果你做的是类似支付这种对实时性要求非常高的业务,那么最直接的方法就是直接读主库。

https://www.bilibili.com/video/BV1KA411Y7tK

https://www.cnblogs.com/wangtao_20/p/6711144.html

https://baijiahao.baidu.com/s?id=1716665877638503200&wfr=spider&for=pc


This entry was posted in 数据库 and tagged , . Bookmark the permalink.
月小升QQ 2651044202, 技术交流QQ群 178491360
首发地址:月小升博客https://java-er.com/blog/mysql-master-slave-delay/
无特殊说明,文章均为月小升原创,欢迎转载,转载请注明本文地址,谢谢
您的评论是我写作的动力.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

*