彻底解决的策略
方案1. 业务妥协,从主库读
方案2. 同步写入缓存redis,修改完成5分钟内都直接从redis读。
其他让延迟变好的策略
1.并行复制 2.降低并发,增加机器
2023.1.16 更新思维导图
随着日益增长的访问量,单台数据库的能力已经捉襟见肘。因此采用主库写数据,从库读数据这种将读写分离开的主从架构便随之衍生了出来。
想要了解主从同步原理,首先得记住两个很重要的日志文件
binlog(二进制日志文件)
relay log(中继日志文件)
通过监控 show slave status 命令输出的Seconds_Behind_Master参数的值来判断:
NULL,表示io_thread或是sql_thread有任何一个发生故障;
0,该值为零,表示主从复制良好;
正值,表示主从已经出现延时,数字越大表示从库延迟越严重。
BinLog的问题
Relay Log的问题
MySQL的主从复制都是单线程的操作,主库对所有DDL和DML产生的日志写进binlog,由于binlog是顺序写,所以效率很高。Slave的SQL Thread线程将主库的DDL和DML操作事件在slave中重放。DML和DDL的IO操作是随机的,不是顺序的,成本高很多。所以SQL Thread线程的速度赶不上主库学binlog的速度,就会产生主从延迟
一句话:日志文件binlog线程的IO是顺序写磁盘,而负责同步的SQL 线程是随机写磁盘
从库除了同步以外还会需要支持正常的业务查询操作,而如果当前需要修改的数据被访问了,那么此时SQL线程就会先进行等待,直到锁被释放以后,再获取锁进行修改。而这一段时间,就有可能导致主从延迟。
一句话:正好relayLog 要修改数据被访问了。
出现慢SQL,慢SQL会导致relayLog较久才能写入到数据库中,进而造成主从延迟。
高并发情况下产生的DML数量超过了SQL Thread所能处理的速度时,那么此时就会产生主从延迟。
既然 SQL 单线程进行重放时速度有限,那么能不能采用多线程的方式来进行重放呢?MySQL 5.6 版本后,提供了一种并行复制的方式,通过将 SQL 线程转换为多个 work 线程来进行重放,这样就解决了主从延迟的问题
如果你理解了随机重放这个导致主从延迟的原因,那么就比较好理解了,控制主库写入的速度,主从延迟发生的概率自然就小了。
如果你做的是类似支付这种对实时性要求非常高的业务,那么最直接的方法就是直接读主库。
https://java-er.com/blog/mysql-zhu-cong-write/
1.半同步复制
2.开启并行复制
DML(data manipulation language)是数据操纵语言:它们是SELECT、UPDATE、INSERT、DELETE,就象它的名字一样,这4条命令是用来对数据库里的数据进行操作的语言。
DDL(data definition language)是数据定义语言:DDL比DML要多,主要的命令有CREATE、ALTER、DROP等,DDL主要是用在定义或改变表(TABLE)的结构,数据类型,表之间的链接和约束等初始化工作上,他们大多在建立表时使用。
DCL(DataControlLanguage)是数据库控制语言:是用来设置或更改数据库用户或角色权限的语句,包括(grant,deny,revoke等)语句。
https://www.bilibili.com/video/BV1KA411Y7tK
https://www.cnblogs.com/wangtao_20/p/6711144.html
https://blog.csdn.net/Laugh_xiaoao/article/details/127033658
https://baijiahao.baidu.com/s?id=1716665877638503200&wfr=spider&for=pc