本篇文章给大家主要讲的是关于MySQL并行复制配置与调优的操作的内容,感兴趣的话就一起来看看这篇文章吧,相信看完MySQL并行复制配置与调优的操作对大家多少有点参考价值吧。
并行复制产生的背景:
因为I/O的线程和SQL线程是单线程工作的,而主是可以多线程写入的,所以主从难免造成延迟
基于此,在5.6,5.7,8.0版本都在SQL线程上实现了多线程,来提升奴隶的并发度
为什么不是I/O多线程?
I/O没必要多线程,因为I/O线程并不是瓶颈啊(没怎么理解)
并行复制的目的:
让奴隶SQL线程尽可能以多线程工作,解决复制延迟的问题
并行复制实现的前提:
能够进行并行复制,关键在于多事务之间是否有锁冲突
MySQL5.6基于模式的并行复制:
应用场景:
比较适用于一个库中有多个模式的场景
并行复制的原理:
MySQL5.6开启并行复制功能后,SQL线程变成协调员线程,由其判断是否可以并发执行,这意味着一个工人线程可以处理一个数据库的连续事务,而不用等待其它数据库完成
如果可以并行执行,选择工人线程执行二进制日志
如果不可以并行执行,如:DDL或者跨模式操作,则等待所有的工人线程执行完成之后再执行当前日志
摘自网上的一张图片,供参考理解:
基于模式的并行复制带来的问题:
因为MySQL5.6并行复制只是基于模式,但对于单库多表的复制场景是无法实现的,甚至性能可能还达不到原来的单线程复制,而在实际工作中单库多表比多库多表的场景更为常见。
MySQL5.6基于模式级别的并发复制可以解决业务表放在不同的数据库下同步延迟的问题,但是在实际生产中大部分表还是放在同一个库中的,这种情况即使设置slave_parallel_workers大于0,也无法进行并发。在高并发的情况下,依然会造成主从复制延迟
MySQL5.6并行复制开启:(前提是配置好主从复制环境)
mysql>停止奴隶;
查询好,0行影响(0.03秒)
mysql>集全球slave_parallel_workers=8;
查询好,0行影响(0.05秒)
mysql>开始奴隶;
查询好,0行影响,1警告(0.07秒)
MySQL5.6并行复制原理图:
并行复制参数说明:
slave_parallel_workers:
的灌肠器线程数量的并行执行复制事务。值0表示禁止奴隶多线程。不支持的MySQL集群
MySQL5.7并行复制原理:
基于组复制(集团提交)实现
如何知道事务是否在同一组中?
在MySQL 5.7版本中,其设计方式是将组提交的信息存放在GTID中。那么如果用户没有开启GTID功能,即:将参数gtid_mode设置为呢?
MySQL 5.7引入了称之为Anonymous_Gtid (ANONYMOUS_GTID_LOG_EVENT)的二进制日志事件类型,组提交信息存放在Anonymous_Gtid中。
当开启GTID时,每一个操作语句(DML/DDL)执行前就会添加一个GTID事件,记录当前全局事务ID;同时在MySQL 5.7版本中,组提交信息也存放在GTID事件中,有两个关键字段last_committed, sequence_number就是用来标识组提交信息的。在InnoDB中有一个全局计数器(全局计数器),在每一次存储引擎提交之前,计数器值就会增加。在事务进入准备阶段之前,全局计数器的当前值会被储存在事务中,这个值称为此事务的commit-parent(也就是last_committed) .last_committed表示事务提交的时候,上次事务提交的编号,如果事务具有相同的last_committed,表示这些事务都在一组内,可以进行并行的回放。而sequence_number是顺序增长的,每个事务对应一个序列号。
这意味着在MySQL 5.7版本中即使不开启GTID,每个事务开始前也是会存在一个Anonymous_Gtid,而这个Anonymous_Gtid事件中就存在着组提交的信息。反之,如果开启了GTID后,就不会存在这个Anonymous_Gtid了,从而组提交信息就记录在非匿名GTID事件中。
MySQL如何将这些事务进行分组的?
一个组提交的事务都是可以并行回放,因为这些事务都已进入到事务的准备阶段,则说明事务之间没有任何冲突(否则就不可能提交)
MySQL5.7并行复制简介:
1) MySQL 5.7才可称为真正的并行复制,这其中最为主要的原因就是奴隶云服务器的回放与大师是一致的,即主云服务器上是怎么并行执行的,那么奴隶上就怎样进行并行回放。不再有库的并行复制限制,对于二进制日志格式也无特殊的要求(基于库的并行复制也没有要求)
