一、缘起

mysql主从复制,读写分离是互联网用的非常多的mysql架构,主从复制最令人诟病的地方就是,在数据量较大并发量较大的场景下,主从延时会比较严重。

为什么mysql主从延时这么大?


回答:从库使用【单线程】重放relaylog。

优化思路是什么?

回答:使用单线程重放relaylog使得同步时间会比较久,导致主从延时很长,优化思路不难想到,可以【多线程并行】重放relaylog来缩短同步时间。

mysql如何“多线程并行”来重放relaylog,是本文要分享的主要内容。

二、如何多线程并行重放relaylog


通过多个线程来并行重放relaylog是一个很好缩短同步时间的思路,但实施之前要解决这样一个问题:

如何来分割relaylog,才能够让多个work-thread并行操作数据data时,使得data保证一致性?

首先,【随机的分配relaylog肯定是不行的】,假设relaylog中有这样三条串行的修改记录:

update account set money=100 where uid=58;

update account set money=150 where uid=58;

update account set money=200 where uid=58;

串行执行:肯定能保证与主库的执行序列一致,最后得到money=200

随机分配并行执行:3个工作线程并发执行这3个语句,谁最后执行成功是不确定的,故得到的数据可能与主库不同

好,对于这个问题,可以用什么样的思路来解决呢(大伙怎么想,mysql团队其实也就是这么想的)

【方法一:相同库上的写操作,用相同的work-thread来重放relaylog;不同库上的写操作,可以用多个work-thread并发来重放relaylog】


如何做到呢?

回答:不难,hash(db-name) % thread-num,库名hash之后再模上线程数,就能够做到。

存在的不足?

很多公司对mysql的使用是“单库多表”,如果是这样的话,仍然是同一个work-thread在串行执行,还是不能提高relaylog的重放速度。

优化方案:将“单库多表”的模式升级为“多库多表”的模式。

其实,数据量大并发量大的互联网业务场景,“多库”模式还具备着其他很多优势,例如:

(1)非常方便的实例扩展:dba很容易将不同的库扩展到不同的实例上

(2)按照业务进行库隔离:业务解耦,进行业务隔离,减少耦合与相互影响

(3)…

对于架构师进行架构设计的启示是:使用多库的方式设计db架构,能够降低主从同步的延时。

新的想法:“单库多表”的场景,还有并行执行优化余地么?

仔细回顾和思考,即使只有一个库,数据的修改和事务的执行在主库上也是并行操作的,既然在主库上可以并行操作,在从库上为啥就不能并行操作,而要按照库来串行执行呢(表示不服)?

新的思路:将主库上同时并行执行的事务,分为一组,编一个号,这些事务在从库上的回放可以并行执行(事务在主库上的执行都进入到prepare阶段,说明事务之间没有冲突,否则就不可能提交),没错,mysql正是这么做的。

【方法二:基于GTID的并行复制】

新版的mysql,将组提交的信息存放在GTID中,使用mysqlbinlog工具,可以看到组提交内部的信息:

20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=1

20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=2

20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=3

20160607 23:22 server_id 58 XXX GTID last_committed=0 sequence_numer=4


和原来的日志相比,多了last_committed和sequence_number。

last_committed表示事务提交时,上次事务提交的编号,如果具备相同的last_committed,说明它们在一个组内,可以并发回放执行。

三、结尾

从mysql并行复制缩短主从同步时延的思想可以看到,架构的思路是相同的:

(1)多线程是一种常见的缩短执行时间的方法

(2)多线程并发分派任务时必须保证幂等性:mysql的演进思路,提供了“按照库幂等”,“按照commit_id幂等”两种方式,思路大伙可以借鉴

另,mysql在并行复制上的逐步优化演进:

mysql5.5 -> 不支持并行复制,对大伙的启示:升级mysql吧

mysql5.6 -> 按照库并行复制,对大伙的启示:使用“多库”架构吧

mysql5.7 -> 按照GTID并行复制

我不是mysql的开发人员,也不是专业的dba,本文仅为一个思路的分享,希望大伙有收获,如果不对也欢迎随时指出。

【文章转载自微信公众号“架构师之路”】

【58沈剑架构系列】mysql并行复制优化思路的更多相关文章

  1. 【58沈剑架构系列】主从DB与cache一致性

    本文主要讨论这么几个问题: (1)数据库主从延时为何会导致缓存数据不一致 (2)优化思路与方案 一.需求缘起 上一篇<缓存架构设计细节二三事>中有一个小优化点,在只有主库时,通过“串行化” ...

  2. 【58沈剑架构系列】互联网公司为啥不使用mysql分区表?

    缘起:有个朋友问我分区表在58的应用,我回答不出来,在我印象中,百度.58都没有听说有分区表相关的应用,业内进行一些技术交流的时候也更多的是自己分库分表,而不是使用分区表.于是去网上查了一下,并询问了 ...

  3. 【58沈剑架构系列】RPC-client异步收发核心细节?

    第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 第三章聊了[“为什么说要搞定微服务架构,先搞定RPC框架?”] 上一章聊了[“微服务架构之RPC- ...

  4. 【58沈剑架构系列】DB主从一致性架构优化4种方法

    需求缘起 大部分互联网的业务都是“读多写少”的场景,数据库层面,读性能往往成为瓶颈.如下图:业界通常采用“一主多从,读写分离,冗余多个读库”的数据库架构来提升数据库的读性能. 这种架构的一个潜在缺点是 ...

  5. 【58沈剑架构系列】lvs为何不能完全替代DNS轮询

    上一篇文章“一分钟了解负载均衡的一切”引起了不少同学的关注,评论中大家争论的比较多的一个技术点是接入层负载均衡技术,部分同学持这样的观点: 1)nginx前端加入lvs和keepalived可以替代“ ...

  6. 【58沈剑架构系列】微服务架构之RPC-client序列化细节

    第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 上一篇聊了[“为什么说要搞定微服务架构,先搞定RPC框架?”] 通过上篇文章的介绍,知道了要实施微 ...

  7. 【58沈剑架构系列】为什么说要搞定微服务架构,先搞定RPC框架?

    第一章聊了[“为什么要进行服务化,服务化究竟解决什么问题”] 第二章聊了[“微服务的服务粒度选型”] 今天开始聊一些微服务的实践,第一块,RPC框架的原理及实践,为什么说要搞定微服务架构,先搞定RPC ...

  8. 【58沈剑架构系列】细聊分布式ID生成方法

    一.需求缘起 几乎所有的业务系统,都有生成一个记录标识的需求,例如: (1)消息标识:message-id (2)订单标识:order-id (3)帖子标识:tiezi-id 这个记录标识往往就是数据 ...

  9. KA,连接池居然这么简单? 原创: 58沈剑 架构师之路 3月20日

    KA,连接池居然这么简单? 原创: 58沈剑 架构师之路 3月20日

随机推荐

  1. select()函数

    select(),确定一个或多个套接口的状态,本函数用于确定一个或多个套接口的状态,对每一个套接口,调用者可查询它的可读性.可写性及错误状态信息,用fd_set结构来表示一组等待检查的套接口,在调用返 ...

  2. 四、Kafka 核心源码剖析

    一.Kafka消费者源码介绍 1.分区消费模式源码介绍 分区消费模式直接由客户端(任何高级语言编写)使用Kafka提供的协议向服务器发送RPC请求获取数据,服务器接受到客户端的RPC请求后,将数据构造 ...

  3. 动态改变swiper的属性

    <script> var mySwiper = new Swiper('.swiper-container',{ autoplay : 1000, autoplayDisableOnInt ...

  4. 解决IE6中 PNG图片透明的终极方案-八种方案!

    “珍惜生命,远离IE6”,IE6中的bug令很多Web前端开发人员实为头疼,因此不知道烧了多少脑细胞,在众多的Bug中最令人抓狂的就是IE对png图片的不支持,导致设计师和重构师放弃了很多很炫的效果, ...

  5. LintCode 412: Candy

    LintCode 412: Candy 题目描述 有 N 个小孩站成一列.每个小孩有一个评级. 按照以下要求,给小孩分糖果: 每个小孩至少得到一颗糖果. 评级越高的小孩可以得到更多的糖果. 需最少准备 ...

  6. beta版1.1.1

    先期发布的alpha版1.0.0版本通过张硕组的测评,我小组跟进修改了出现的问题. 1.首先解决了互测版本中无法正常退出界面的问题,并有退出提示,(确定,取消). 2.就之前提到的关于前期部分功能的割 ...

  7. Linux基础-软硬连接Block概念

    建立/etc/passwd的软连接文件,放在/tmp目录下 使用文件名方式建立的软连接可以跨分区,删除目标文件后,软连接文件失效 建立/etc/passwd的硬链接文件,放在/boot下,如果不成功, ...

  8. Linux的基础优化-2

    1.启动网卡 ifup eth0 2.SSH链接 ifconfig 查看IP后SSH终端连接3.更新源 最小化安装是没有wget工具的,必须先安装再修改源 yum install wget 备份原系统 ...

  9. required_new spring事务传播行为无效碰到的坑!

    在测试事务传播行为的时候,因为用了同一个service中的方法测试,所以不管怎么设置都无效了: 原因是aop动态代理只会拦截一次执行方法,第二个方法是照搬的,只要调用其他service中的事务方法,传 ...

  10. 【原创】Linux环境下的图形系统和AMD R600显卡编程(1)——Linux环境下的图形系统简介

    Linux/Unix环境下最早的图形系统是Xorg图形系统,Xorg图形系统通过扩展的方式以适应显卡和桌面图形发展的需要,然而随着软硬件的发展,特别是嵌入式系统的发展,Xorg显得庞大而落后.开源社区 ...