深圳网站关键词排名优化,上海网络推广培训,网站构建的开发费用,推广优化方案在上一篇文章中#xff0c;我和你介绍了一主多从的结构以及切换流程。今天我们就继续聊聊一主多从架构的应用场景#xff1a;读写分离#xff0c;以及怎么处理主备延迟导致的读写分离问题。 我们在上一篇文章中提到的一主多从的结构#xff0c;其实就是读写分离的基本结构了…在上一篇文章中我和你介绍了一主多从的结构以及切换流程。今天我们就继续聊聊一主多从架构的应用场景读写分离以及怎么处理主备延迟导致的读写分离问题。 我们在上一篇文章中提到的一主多从的结构其实就是读写分离的基本结构了。这里我再把这张图贴过来方便你理解。 图1 读写分离基本结构 读写分离的主要目标就是分摊主库的压力。图1中的结构是客户端client主动做负载均衡这种模式下一般会把数据库的连接信息放在客户端的连接层。也就是说由客户端来选择后端数据库进行查询。 还有一种架构是在MySQL和客户端之间有一个中间代理层proxy客户端只连接proxy 由proxy根据请求类型和上下文决定请求的分发路由。 图2 带proxy的读写分离架构 接下来我们就看一下客户端直连和带proxy的读写分离架构各有哪些特点。 客户端直连方案因为少了一层proxy转发所以查询性能稍微好一点儿并且整体架构简单排查问题更方便。但是这种方案由于要了解后端部署细节所以在出现主备切换、库迁移等操作的时候客户端都会感知到并且需要调整数据库连接信息。你可能会觉得这样客户端也太麻烦了信息大量冗余架构很丑。其实也未必一般采用这样的架构一定会伴随一个负责管理后端的组件比如Zookeeper尽量让业务端只专注于业务逻辑开发。 带proxy的架构对客户端比较友好。客户端不需要关注后端细节连接维护、后端信息维护等工作都是由proxy完成的。但这样的话对后端维护团队的要求会更高。而且proxy也需要有高可用架构。因此带proxy架构的整体就相对比较复杂。 理解了这两种方案的优劣具体选择哪个方案就取决于数据库团队提供的能力了。但目前看趋势是往带proxy的架构方向发展的。 但是不论使用哪种架构你都会碰到我们今天要讨论的问题由于主从可能存在延迟客户端执行完一个更新事务后马上发起查询如果查询选择的是从库的话就有可能读到刚刚的事务更新之前的状态。 这种“在从库上会读到系统的一个过期状态”的现象在这篇文章里我们暂且称之为“过期读”。 前面我们说过了几种可能导致主备延迟的原因以及对应的优化策略但是主从延迟还是不能100%避免的。 不论哪种结构客户端都希望查询从库的数据结果跟查主库的数据结果是一样的。 接下来我们就来讨论怎么处理过期读问题。 这里我先把文章中涉及到的处理过期读的方案汇总在这里以帮助你更好地理解和掌握全文的知识脉络。这些方案包括 强制走主库方案sleep方案判断主备无延迟方案配合semi-sync方案等主库位点方案等GTID方案。强制走主库方案 强制走主库方案其实就是将查询请求做分类。通常情况下我们可以将查询请求分为这么两类 对于必须要拿到最新结果的请求强制将其发到主库上。比如在一个交易平台上卖家发布商品以后马上要返回主页面看商品是否发布成功。那么这个请求需要拿到最新的结果就必须走主库。 对于可以读到旧数据的请求才将其发到从库上。在这个交易平台上买家来逛商铺页面就算晚几秒看到最新发布的商品也是可以接受的。那么这类请求就可以走从库。 你可能会说这个方案是不是有点畏难和取巧的意思但其实这个方案是用得最多的。 当然这个方案最大的问题在于有时候你会碰到“所有查询都不能是过期读”的需求比如一些金融类的业务。这样的话你就要放弃读写分离所有读写压力都在主库等同于放弃了扩展性。 因此接下来我们来讨论的话题是可以支持读写分离的场景下有哪些解决过期读的方案并分析各个方案的优缺点。 Sleep 方案 主库更新后读从库之前先sleep一下。具体的方案就是类似于执行一条select sleep(1)命令。 这个方案的假设是大多数情况下主备延迟在1秒之内做一个sleep可以有很大概率拿到最新的数据。 这个方案给你的第一感觉很可能是不靠谱儿应该不会有人用吧并且你还可能会说直接在发起查询时先执行一条sleep语句用户体验很不友好啊。 但这个思路确实可以在一定程度上解决问题。为了看起来更靠谱儿我们可以换一种方式。 以卖家发布商品为例商品发布后用AjaxAsynchronous JavaScript XML异步JavaScript和XML直接把客户端输入的内容作为“新的商品”显示在页面上而不是真正地去数据库做查询。 这样卖家就可以通过这个显示来确认产品已经发布成功了。等到卖家再刷新页面去查看商品的时候其实已经过了一段时间也就达到了sleep的目的进而也就解决了过期读的问题。 也就是说这个sleep方案确实解决了类似场景下的过期读问题。但从严格意义上来说这个方案存在的问题就是不精确。这个不精确包含了两层意思 如果这个查询请求本来0.5秒就可以在从库上拿到正确结果也会等1秒 如果延迟超过1秒还是会出现过期读。 看到这里你是不是有一种“你是不是在逗我”的感觉这个改进方案虽然可以解决类似Ajax场景下的过期读问题但还是怎么看都不靠谱儿。别着急接下来我就和你介绍一些更准确的方案。 判断主备无延迟方案 要确保备库无延迟通常有三种做法。 通过前面的第25篇文章我们知道show slave status结果里的seconds_behind_master参数的值可以用来衡量主备延迟时间的长短。 所以第一种确保主备无延迟的方法是每次从库执行查询请求前先判断seconds_behind_master是否已经等于0。如果还不等于0 那就必须等到这个参数变为0才能执行查询请求。 seconds_behind_master的单位是秒如果你觉得精度不够的话还可以采用对比位点和GTID的方法来确保主备无延迟也就是我们接下来要说的第二和第三种方法。 如图3所示是一个show slave status结果的部分截图。 图3 show slave status结果 现在我们就通过这个结果来看看具体如何通过对比位点和GTID来确保主备无延迟。 第二种方法对比位点确保主备无延迟 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_Position1 表示这对主备关系使用了GTID协议。Retrieved_Gtid_Set是备库收到的所有日志的GTID集合Executed_Gtid_Set是备库所有已经执行完成的GTID集合。如果这两个集合相同也表示备库接收到的日志都已经同步完成。 可见对比位点和对比GTID这两种方法都要比判断seconds_behind_master是否为0更准确。 在执行查询请求之前先判断从库是否同步完成的方法相比于sleep方案准确度确实提升了不少但还是没有达到“精确”的程度。为什么这么说呢 我们现在一起来回顾下一个事务的binlog在主备库之间的状态 主库执行完成写入binlog并反馈给客户端 binlog被从主库发送给备库备库收到 在备库执行binlog完成。 我们上面判断主备无延迟的逻辑是“备库收到的日志都执行完成了”。但是从binlog在主备之间状态的分析中不难看出还有一部分日志处于客户端已经收到提交确认而备库还没收到日志的状态。 如图4所示就是这样的一个状态。 图4 备库还没收到trx3 这时主库上执行完成了三个事务trx1、trx2和trx3其中 trx1和trx2已经传到从库并且已经执行完成了 trx3在主库执行完成并且已经回复给客户端但是还没有传到从库中。 如果这时候你在从库B上执行查询请求按照我们上面的逻辑从库认为已经没有同步延迟但还是查不到trx3的。严格地说就是出现了过期读。 那么这个问题有没有办法解决呢 配合semi-sync 要解决这个问题就要引入半同步复制也就是semi-sync replication。 semi-sync做了这样的设计 事务提交的时候主库把binlog发给从库 从库收到binlog以后发回给主库一个ack表示收到了 主库收到这个ack以后才能给客户端返回“事务完成”的确认。 也就是说如果启用了semi-sync就表示所有给客户端发送过确认的事务都确保了备库已经收到了这个日志。 在第25篇文章的评论区有同学问到如果主库掉电的时候有些binlog还来不及发给从库会不会导致系统数据丢失 答案是如果使用的是普通的异步复制模式就可能会丢失但semi-sync就可以解决这个问题。 这样semi-sync配合前面关于位点的判断就能够确定在从库上执行的查询请求可以避免过期读。 但是semi-sync位点判断的方案只对一主一备的场景是成立的。在一主多从场景中主库只要等到一个从库的ack就开始给客户端返回确认。这时在从库上执行查询请求就有两种情况 如果查询是落在这个响应了ack的从库上是能够确保读到最新数据 但如果是查询落到其他从库上它们可能还没有收到最新的日志就会产生过期读的问题。 其实判断同步位点的方案还有另外一个潜在的问题即如果在业务更新的高峰期主库的位点或者GTID集合更新很快那么上面的两个位点等值判断就会一直不成立很可能出现从库上迟迟无法响应查询请求的情况。 实际上回到我们最初的业务逻辑里当发起一个查询请求以后我们要得到准确的结果其实并不需要等到“主备完全同步”。 为什么这么说呢我们来看一下这个时序图。 图5 主备持续延迟一个事务 图5所示就是等待位点方案的一个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。 对于图5中先执行trx1再执行一个查询请求的逻辑要保证能够查到正确的数据我们可以使用这个逻辑 trx1事务更新完成后马上执行show master status得到当前主库执行到的File和Position 选定一个从库执行查询语句 在从库上执行select master_pos_wait(File, Position, 1) 如果返回值是0的正整数则在这个从库执行查询语句 否则到主库执行查询语句。 我把上面这个流程画出来。 图6 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则在这个从库执行查询语句 否则到主库执行查询语句。 跟等主库位点的方案一样等待超时后是否直接到主库查询需要业务开发同学来做限流考虑。 我把这个流程图画出来。 图7 wait_for_executed_gtid_set方案 在上面的第一步中trx1事务更新完成后从返回包直接获取这个事务的GTID。问题是怎么能够让MySQL在执行事务后返回包中带上GTID呢 你只需要将参数session_track_gtids设置为OWN_GTID然后通过API接口mysql_session_track_get_first从返回包解析出GTID的值即可。 在专栏的第一篇文章中我介绍mysql_reset_connection的时候评论区有同学留言问这类接口应该怎么使用。 这里我再回答一下。其实MySQL并没有提供这类接口的SQL用法是提供给程序的API(https://dev.mysql.com/doc/refman/5.7/en/c-api-functions.html)。 比如为了让客户端在事务提交后返回的GITD能够在客户端显示出来我对MySQL客户端代码做了点修改如下所示 图8 显示更新事务的GTID--代码 这样就可以看到语句执行完成显示出GITD的值。 图9 显示更新事务的GTID--效果 当然了这只是一个例子。你要使用这个方案的时候还是应该在你的客户端代码中调用mysql_session_track_get_first这个函数。 小结 在今天这篇文章中我跟你介绍了一主多从做读写分离时可能碰到过期读的原因以及几种应对的方案。 这几种方案中有的方案看上去是做了妥协有的方案看上去不那么靠谱儿但都是有实际应用场景的你需要根据业务需求选择。 即使是最后等待位点和等待GTID这两个方案虽然看上去比较靠谱儿但仍然存在需要权衡的情况。如果所有的从库都延迟那么请求就会全部落到主库上这时候会不会由于压力突然增大把主库打挂了呢 其实在实际应用中这几个方案是可以混合使用的。 比如先在客户端对请求做分类区分哪些请求可以接受过期读而哪些请求完全不能接受过期读然后对于不能接受过期读的语句再使用等GTID或等位点的方案。 但话说回来过期读在本质上是由一写多读导致的。在实际应用中可能会有别的不需要等待就可以水平扩展的数据库方案但这往往是用牺牲写性能换来的也就是需要在读性能和写性能中取权衡。 最后 我给你留下一个问题吧。 假设你的系统采用了我们文中介绍的最后一个方案也就是等GTID的方案现在你要对主库的一张大表做DDL可能会出现什么情况呢为了避免这种情况你会怎么做呢 你可以把你的分析和方案设计写在评论区我会在下一篇文章跟你讨论这个问题。感谢你的收听也欢迎你把这篇文章分享给更多的朋友一起阅读。 上期问题时间 上期给你留的问题是在GTID模式下如果一个新的从库接上主库但是需要的binlog已经没了要怎么做 某、人同学给了很详细的分析我把他的回答略做修改贴过来。 如果业务允许主从不一致的情况那么可以在主库上先执行show global variables like ‘gtid_purged’得到主库已经删除的GTID集合假设是gtid_purged1然后先在从库上执行reset master再执行set global gtid_purged ‘gtid_purged1’最后执行start slave就会从主库现存的binlog开始同步。binlog缺失的那一部分数据在从库上就可能会有丢失造成主从不一致。 如果需要主从数据一致的话最好还是通过重新搭建从库来做。 如果有其他的从库保留有全量的binlog的话可以把新的从库先接到这个保留了全量binlog的从库追上日志以后如果有需要再接回主库。 如果binlog有备份的情况可以先在从库上应用缺失的binlog然后再执行start slave。 转载于:https://www.cnblogs.com/gaosf/p/11149734.html
