作者|莱乌
写这篇文章是因为之前有一次删库操作,需要进行批量删除数据,当时没有控制好删除速度
,导致产生了主从延迟,出现了一点小事故。
今天我们就来看看为什么会产生主从延迟以及主从延迟如何处理等相关问题。
坐好了,准备发车!
- 思维导图 -
随着日益增长的访问量,单台数据库的应接能力已经捉襟见肘。因此采用主库写数据,从库读数据这种将读写分离开的主从架构便随之衍生了出来。
在生产环境中,常见的主从架构有很多种,在这里给大家介绍几种比较常见的架构模式。
了解了主从的基本架构及相关配置后,下面就要进入正题了。
对于主从来说,通常的操作是主库用来写入数据,从库用来读取数据。这样的好处是通过将读写压力分散开,避免了所有的请求都打在主库上。同时通过从库进行水平扩展使系统的伸缩性及负载能力也得到了很大的提升。
但是问题就来了,读从库时的数据要与主库保持一致,那就需要主库的数据在写入后同步到从库中。如何保持主库与从库的数据一致性,主库又是通过什么样的方式将数据实时同步到从库的?
基本原理
Mysql 中主从复制时有两个很重要的日志文件:
-
bin
log(
二进制日志文件
)
-
relay log(
中继日志文件
)
在主从同步的过程中,主库会将所有的操作事件记录在 binlog 中,从库通过开启一个 I/O 线程保持与主库的通信,并在一定时间间隔内探测 binlog 日志文件是否发生改变。如果 binlog 日志发生了变化,主库生成一个 binlog dump 线程向从库 I/O 线程传送 binlog。从库上的 I/O 线程将 binlog 复制到自己的 relay log 中。最终由从库中的 SQL 线程读取 relay log 中的事件重放到从库上。
上面的流程我们已经知道了主从复制的相关过程了,但是主库有更新就会同步从库,那为什么会出现主从延迟的情况呢?
随机重放
Mysql 主库中写 binlog 的操作是顺序写的,之前我们提到过,磁盘的顺序读写速度是很快的。同样的,从库中的 I/O 线程操作日志的速度效率也是很高的。但是别忘了,还有一个 SQL