一主多从架构的应用场景:读写分离,以及怎么处理主备延迟导致的读写分离问题。
读写分离的主要目标就是分摊主库的压力
- 可以由客户端主动做负载均衡,把数据库的连接信息放在客户端的连接层。也就是说,由客户端来选择后端数据库进行查询
- 在MySQL和客户端之间有一个中间代理层proxy,客户端只连接proxy, 由proxy根据请求类型和上下文决定请求的分发路由。
- 图1带proxy的读写分离架构
客户端直连特点:- 少一层proxy转发,查询性能稍微好点;整体架构简单,排查问题更方便。
- 由于要了解后端部署细节,所以在出现主备切换、库迁移等操作的时候,客户端都会感知到,并且需要调整数据库连接信息。
- 负责管理后端的组件,比如Zookeeper,尽量让业务端只专注于业务逻辑开发。
proxy架构 - 对客户端比较友好,客户端不需要关注后端细节,连接维护、后端信息维护等工作,都是由proxy完成的。
- 对后端维护团队的要求会更高,proxy也需要有高可用架构。因此,带proxy架构的整体就相对比较复杂。
主从延迟
- 过期读:在从库上会读到系统的一个过期状态”的现象。
- 解决方案:
- 强制走主库方案
- sleep方案
- 判断主备无延迟方案
- 配合semi-sync的方案
- 等主库位点方案
- 等GTID方案
强制走主库方案
强制走主库方案其实就是,将查询请求做分类。通常情况下,我们可以将查询请求分为这么两类:
-
对于必须要拿到最新结果的请求,强制将其发到主库上。比如,在一个交易平台上,卖家发布商品以后,马上要返回主页面,看商品是否发布成功。那么,这个请求需要拿到最新的结果,就必须走主库。
-
对于可以读到旧数据的请求,才将其发到从库上。在这个交易平台上,买家来逛商铺页面,就算晚几秒看到最新发布的商品,也是可以接受的。那么,这类请求就可以走从库。
有时候你会碰到“所有查询都不能是过期读”的需求,比如一些金融类的业务。这样的话,你就要放弃读写分离,所有读写压力都在主库,等同于放弃了扩展性。
Sleep 方案
主库更新后,读从库之前先sleep一下。具体的方案就是,类似于执行一条select sleep(1)命令。
这个方案的假设是,大多数情况下主备延迟在1秒之内,做一个sleep可以有很大概率拿到最新的数据。
这个方案给你的第一感觉,很可能是不靠谱儿,应该不会有人用吧?并且,你还可能会说,直接在发起查询时先执行一条sleep语句,用户体验很不友好啊。
但,这个思路确实可以在一定程度上解决问题。为了看起来更靠谱儿,我们可以换一种方式。
以卖家发布商品为例,商品发布后,用Ajax(Asynchronous JavaScript + XML,异步JavaScript和XML)直接把客户端输入的内容作为“新的商品”显示在页面上,而不是真正地去数据库做查询。
这样,卖家就可以通过这个显示,来确认产品已经发布成功了。等到卖家再刷新页面,去查看商品的时候,其实已经过了一段时间,也就达到了sleep的目的,进而也就解决了过期读的问题。
也就是说,这个sleep方案确实解决了类似场景下的过期读问题。但,从严格意义上来说,这个方案存在的问题就是不精确。这个不精确包含了两层意思:
如果这个查询请求本来0.5秒就可以在从库上拿到正确结果,也会等1秒;
如果延迟超过1秒,还是会出现过期读。
看到这里,你是不是有一种“你是不是在逗我”的感觉,这个改进方案虽然可以解决类似Ajax场景下的过期读问题,但还是怎么看都不靠谱儿。别着急,接下来我就和你介绍一些更准确的方案。
判断主备无延迟方案
要确保备库无延迟,通常有三种做法
- 第一种:show slave status结果里的seconds_behind_master参数的值,可以用来衡量主备延迟时间的长短。,每次从库执行查询请求前,先判断seconds_behind_master(单位是秒)是否已经等于0。如果还不等于0 ,那就必须等到这个参数变为0才能执行查询请求。
图2 show slave status结果
- 第二种方法,对比位点确保主备无延迟:
- Master_Log_File和Read_Master_Log_Pos,表示的是读到的主库的最新位点;
- Relay_Master_Log_File和Exec_Master_Log_Pos,表示的是备库执行的最新位点。如果Master_Log_File和Relay_Master_Log_File、Read_Master_Log_Pos和Exec_Master_Log_Pos这两组值完全相同,就表示接收到的日志已经同步完成
- 第三种方法,对比GTID集合确保主备无延迟:
- Auto_Position=1 ,表示这对主备关系使用了GTID协议。
- Retrieved_Gtid_Set,是备库收到的所有日志的GTID集合;
- Executed_Gtid_Set,是备库所有已经执行完成的GTID集合。
如果这两个集合相同,也表示备库接收到的日志都已经同步完成。
特点:对比位点和对比GTID这两种方法,都要比判断seconds_behind_master是否为0更准确。
在执行查询请求之前,先判断从库是否同步完成的方法,相比于sleep方案,准确度确实提升了不少,但还是没有达到“精确”的程度。为什么这么说呢?
再来回顾下,一个事务的binlog 在主备库之间的状态:
1 主库执行万册灰姑娘,写入binlog,并反馈给客户端;
2 binlog被从主库发送给备库,备库收到;
3 在备库执行binlog完成
我们上面判断主备无延迟的逻辑,是“备库收到的日志都执行完成了”。但是,从binlog在主备之间状态的分析中,不难看出还有一部分日志,处于客户端已经收到提交确认,而备库还没收到日志的状态。
图 3 备库还没收到trx3
这时,主库上执行完成了三个事务trx1、trx2和trx3,其中:
trx1和trx2已经传到从库,并且已经执行完成了;
trx3在主库执行完成,并且已经回复给客户端,但是还没有传到从库中。
如果这时候你在从库B上执行查询请求,按照我们上面的逻辑,从库认为已经没有同步延迟,但还是查不到trx3的。严格地说,就是出现了过期读。
如何解决呢?
配合semi-sync
要解决这个问题,就要引入半同步复制,也就是semi-sync replication。
semi-sync做了这样的设计:
事务提交的时候,主库把binlog发给从库;
从库收到binlog以后,发回给主库一个ack,表示收到了;
主库收到这个ack以后,才能给客户端返回“事务完成”的确认。
也就是说,如果启用了semi-sync,就表示所有给客户端发送过确认的事务,都确保了备库已经收到了这个日志。
问题:如果主库掉电的时候,有些binlog还来不及发给从库,会不会导致系统数据丢失?
答:是,如果使用的是普通的异步复制模式,就可能会丢失,但semi-sync就可以解决这个问题。
这样,semi-sync配合前面关于位点的判断,就能够确定在从库上执行的查询请求,可以避免过期读。
但是,semi-sync+位点判断的方案,只对一主一备的场景是成立的。在一主多从场景中,主库只要等到一个从库的ack,就开始给客户端返回确认。这时,在从库上执行查询请求,就有两种情况:
如果查询是落在这个响应了ack的从库上,是能够确保读到最新数据;
但如果是查询落到其他从库上,它们可能还没有收到最新的日志,就会产生过期读的问题。其实,判断同步位点的方案还有另外一个潜在的问题,即:如果在业务更新的高峰期,主库的位点或者GTID集合更新很快,那么上面的两个位点等值判断就会一直不成立,很可能出现从库上迟迟无法响应查询请求的情况。
实际上,回到我们最初的业务逻辑里,当发起一个查询请求以后,我们要得到准确的结果,其实并不需要等到“主备完全同步”。
为什么这么说呢?我们来看一下这个时序图。
图4主备持续延迟一个事务
图4所示,就是等待位点方案的一个bad case。图中备库B下的虚线框,分别表示relaylog和binlog中的事务。可以看到,图5中从状态1 到状态4,一直处于延迟一个事务的状态。
备库B一直到状态4都和主库A存在延迟,如果用上面必须等到无延迟才能查询的方案,select语句直到状态4都不能被执行。
但是,其实客户端是在发完trx1更新后发起的select语句,我们只需要确保trx1已经执行完成就可以执行select语句了。也就是说,如果在状态3执行查询请求,得到的就是预期结果了。
semi-sync配合判断主备无延迟的方案,存在两个问题:
-
一主多从的时候,在某些从库执行查询请求会存在过期读的现象;
-
在持续延迟的情况下,可能出现过度等待的问题。
接下来,我要和你介绍的等主库位点方案,就可以解决这两个问题。
等主库位点方案
要理解等主库位点方案,我需要先和你介绍一条命令:
select master_pos_wait(file, pos[, timeout]);
这条命令的逻辑如下:
-
它是在从库执行的;
-
参数file和pos指的是主库上的文件名和位置;
-
timeout可选,设置为正整数N表示这个函数最多等待N秒。
这个命令正常返回的结果是一个正整数M,表示从命令开始执行,到应用完file和pos表示的binlog位置,执行了多少事务。
当然,除了正常返回一个正整数M外,这条命令还会返回一些其他结果,包括:
-
如果执行期间,备库同步线程发生异常,则返回NULL;
-
如果等待超过N秒,就返回-1;
-
如果刚开始执行的时候,就发现已经执行过这个位置了,则返回0。
对于图4中先执行trx1,再执行一个查询请求的逻辑,要保证能够查到正确的数据,我们可以使用这个逻辑:
-
trx1事务更新完成后,马上执行show master status得到当前主库执行到的File和Position;
-
选定一个从库执行查询语句;
-
在从库上执行select master_pos_wait(File, Position, 1);
-
如果返回值是>=0的正整数,则在这个从库执行查询语句;
-
否则,到主库执行查询语句。
我把上面这个流程画出来:
图5 master_pos_wait方案
这里我们假设,这条select查询最多在从库上等待1秒。那么,如果1秒内master_pos_wait返回一个大于等于0的整数,就确保了从库上执行的这个查询结果一定包含了trx1的数据。
步骤5到主库执行查询语句,是这类方案常用的退化机制。因为从库的延迟时间不可控,不能无限等待,所以如果等待超时,就应该放弃,然后到主库去查。
你可能会说,如果所有的从库都延迟超过1秒了,那查询压力不就都跑到主库上了吗?确实是这样。
但是,按照我们设定不允许过期读的要求,就只有两种选择,一种是超时放弃,一种是转到主库查询。具体怎么选择,就需要业务开发同学做好限流策略了。
GTID方案
如果你的数据库开启了GTID模式,对应的也有等待GTID的方案。
MySQL中同样提供了一个类似的命令:
select wait_for_executed_gtid_set(gtid_set, 1);
这条命令的逻辑是:
等待,直到这个库执行的事务中包含传入的gtid_set,返回0;
超时返回1。
在前面等位点的方案中,我们执行完事务后,还要主动去主库执行show master status。而MySQL 5.7.6版本开始,允许在执行完更新类事务后,把这个事务的GTID返回给客户端,这样等GTID的方案就可以减少一次查询。
这时,等GTID的执行流程就变成了:
trx1事务更新完成后,从返回包直接获取这个事务的GTID,记为gtid1;
选定一个从库执行查询语句;
在从库上执行 select wait_for_executed_gtid_set(gtid1, 1);
如果返回值是0,则在这个从库执行查询语句;
否则,到主库执行查询语句。
跟等主库位点的方案一样,等待超时后是否直接到主库查询,需要业务开发同学来做限流考虑。
我把这个流程图画出来。
图6wait_for_executed_gtid_set方案
在上面的第一步中,trx1事务更新完成后,从返回包直接获取这个事务的GTID。问题是,怎么能够让MySQL在执行事务后,返回包中带上GTID呢?
你只需要将参数session_track_gtids设置为OWN_GTID,然后通过API接口mysql_session_track_get_first从返回包解析出GTID的值即可。
比如,为了让客户端在事务提交后,返回的GITD能够在客户端显示出来,我对MySQL客户端代码做了点修改,如下所示:
要使用这个方案的时候,还是应该在你的客户端代码中调用mysql_session_track_get_first这个函数。
总结:
- 过期读:由于主从可能存在延迟,客户端执行完一个更新事务后马上在从库发起查询,就有可能读到刚刚的事务更新之前的状态。
- 解决方案:
- 强制走主库方案;
- sleep方案;
- 判断主备无延迟方案;
- seconds_behind_master = 0
- Master_Log_File和Read_Master_Log_Pos相等
- Relay_Master_Log_File和Exec_Master_Log_Pos相等
- Retrieved_Gtid_Set和Executed_Gtid_Set 相等
- 配合semi-sync方案;
- 等主库位点方案;
- 等GTID方案。
- 解决方案: