如何解决主从数据库同步延迟问题?
前言
- 最近,系统上频繁出现主从延迟的问题,因此针对主从架构、主从同步以及主从延迟问题进行了一次学习。
主从架构浅析
- 在了解主从延迟之前,我们有必要对主从架构有一些简单的认识。在如今的互联网架构中,单点数据库架构往往不能满足日常的访问请求。为了增大系统的吞吐量、实现高可用架构,系统数据库往往会采用集群搭建。而集群架构中,最常见的就是主从架构。
常见主从架构介绍
- 主从架构作为最常见的集群搭建模式,通过将读写分离,来避免所有的请求都请求到同一个数据库上,从而减少单个数据库的压力。其次,通过对从库进行水平的扩展,也会使得系统的伸缩性及负载能力得到提升。常见的主从架构主要有以下几种:
- 一主一从式
- 一主一从为最常见的主从架构模式,由一个主节点+一个从节点组合而成,当主节点宕机时,从节点可以快速接替主节点的工作。
- 一主多从式
- 该架构有一个主节点+多个从节点组成,适合读较多的场景,可以将读命令分摊到多个从节点。
- 在一主多从的基础上,为了减轻主库向从库同步数据的压力,还出现了树状主从/级连复制的架构:
- 多主一从
- 在一些需要汇总数据进行分析,或写入压力较大的情况,会采用多主一从的架构模式。该架构由多个主节点+一个从节点组成。
- 主主互 备式
- 主主互备的架构模式,主要由两个或多个的主节点构成,每个主节点的更新操作都需要向其余的主节点进行同步。优点是读写的压力均可以通过负载均衡进行分摊,提升系统的吞吐量,且其中一个节点宕机,也不会影响整个系统,实现高可用。
- 但是这种模式也存在缺陷。在实现数据双向同步的过程中,双向复制可能会带来延迟问题,极端情况下有可能数据丢失。另外,数据库数量增加会导致数据同步问题变得极为复杂
主从同步
- 聊完了常见的主从架构,那么这些架构,都是如何实现的主从数据库数据的同步的呢?以下就以mysql数据库为例子进行学习、了解。在mysql中,实现主从同步有两个比较重要的日志文件:binLog和relayLog。
binlog
- binlog,又称为二进制日志文件。简要来说,binLog主要记录
当前数据库发生了什么
。其主要日志格式有三种:statement、row 和 mixed, - statement:statement又被称为
基于SQL语句的复制
。在该格式下,binlog内会记录执行的SQL原文。但在一些极端的情况下,可能会因为主从数据库的配置、索引等,同一句SQL可能执行出来的结果是不一致的。 - row:row又被称为
基于行的复制
,故名思义,row模式下记录的不是SQL的原文,而是记录的SQL语句影响的数据。例如哪一行数据被删除了、哪一行数据从a更新成了b等等。这样可以避免因为执行SQL的环境不同导致的数据不一致,但是缺陷就是会产生大量的日志文件。 - mixed:从5.1.8版本开始,MySQL提供了Mixed格式,实际上就是statement与row的结合。在该模式下,一般的语句修改使用statement保存binlog,但是一些函数statement无法完成主从复制,那么此时就会使用row格式进行保存。
- 具体的,我们可以使用语句
show binary logs
来查看当前数据库的binlog。
relayLog
- relayLog,又被称为中继日志。简单来说,relayLog中主要保存了从主节点中查询出来的binlog数据,供从节点在同步的过程中使用。
同步原理分析
- 在了解了binLog及relayLog之后,我们就可以开始了解mysql是如何进行数据同步的了。如图所示,mysql的同步过程主要有以下几个步骤:
- 主节点产生数据变更,此时会将变更内容写入binLog,同时会开启binlog dump线程将更新的数据信息同步给从库。
- 从节点的I/O线程读取到变更的数据后,会将数据写入relayLog。
- 从节点的SQL线程检测到relayLog中添加了数据后,会将新增的数据写入到从库中,从而实现主从数据的同步。
主从延迟
- 了解了主从同步的原理,我们就来了解下什么是主从延迟。主从延迟简单来说,是因为在一定时间内,主节点此时已经完成了数据的写入,但是此时从库还没有将主库的数据同步更新完成。
- 结合上述的主从同步原理,不难推断造成主从延迟主要是源于以下几个方面之一:
- 主节点binLog数据未及时同步
- 从节点I/O线程未及时将数据写入RelayLog
- 从节点SQL线程未及时将RelayLog写入数据库
- 针对这三个方面,我们逐一分析可能导致主从延迟的原因。
主从延迟的原因
主节点binLog数据未及时同步
- 针对主库binLog数据没及时同步造成主从延迟的情况,可能性主要有如下几个:
- 主库存在高并发,某一时刻,大量的写请求到主库上,意味着binLog需要进行频繁的写入及同步,此时就可能导致主节点binlog dump线程、从节点I/O线程没法及时同步,从而造成主从延迟。
- 网络IO存在问题,某一时刻如果网络IO挂掉了,数据没法发送到从库,那么此时也会导致从库的数据无法更新,造成主从延迟。
- 执行大事务,一旦执行大事务,主库必须等到事务执行完成之后才能写入binLog,进而也会影响后续的binLog的同步及写入,造成主从延迟。
I/O线程未及时写RelayLog
- 针对从节点I/O线程未及时写入RelayLog情况,其主要的可能性是
- 存在高并发,I/O线程未能及时将数据刷入到relayLog中。但I/O线程通常为磁盘读写,效率较快,一般不会成为主要的问题。
- 机器性能较差,导致relayLog同步速度较慢。
SQL线程未及时写数据库
- 针对这最后一种情况,产生主从延迟的原因可能更多一些:
- relayLog随机重放。在
主库中写binlog
及从库中写relayLog
都是顺序进行的磁盘读写,效率较高。但是SQL数据对relayLog进行数据重放的时候是随机写盘的,执行效率相对较慢,从而出现主从延迟。 - 锁等待,从库除了同步以外还会需要支持正常的业务查询操作,而如果当前需要修改的数据被访问了,那么此时SQL线程就会先进行等待,直到锁被释放以后,再获取锁进行修改。而这一段时间,就有可能导致主从延迟。
- 高并发,高并发情况下产生的DML数量超过了SQL Thread所能处理的速度时,那么此时就会产生主从延迟。
- 出现慢SQL,慢SQL会导致relayLog较久才能写入到数据库中,进而造成主从延迟。
如何解决主从延迟
- 了解了出现主从延迟的原因,那么如何对主从延迟进行解决呢?可行的方案我这里简单总结了三个:
强一致性方案
- 最简单粗暴的方案,其实就是针对一些实时性要求比较高的操作,通过代码指定的方式,强行让查询语句走主库进行查询。这样可以保证数据的绝对准确,带来的问题是会加大主库的并发数量,增加宕机的风险。
并行复制
- 这种方案主要针对高并发情况下从库SQL单线程出现瓶颈的时候使用,将SQL线程转化成多个线程来进行重放,加快对DML数据的处理速度,从而减缓主从延迟。mySql自5.7版本后就已经支持并行复制了。可以在从服务上设置
slave_parallel_workers
为一个大于0的数,然后把slave_parallel_type
参数设置为LOGICAL_CLOCK
即可。
降低并发
- 针对过高的并发,其实会导致同步过程的三个阶段都会出现问题,为此,在接口设计时,要充分考虑接口的请求量,并适当采用如
令牌桶、漏桶
算法等进行限流。或采用分布式锁
等对关键数据进行加锁,控制并发量,减少主从延迟对业务的影响。
增加NOSQL层
- 通过在从库前增加NOSQL层来缓解,主库写入SQL的时候,按照一定策略将关键数据放入到缓存中,查询时优先查询缓存中的数据。可以在一定程度上减少主从延迟所带来的问题。
总结
- 归根结底来说,在主从架构下,主从延迟其实是不可避免的(只是延迟的时间长短)。但是通对主从延迟原因的合理分析以及的合适方案选择,可以最大程度上缩短主从同步时间,最大程度减少主从延迟给系统、服务带来的影响的。