谈谈MySQL的WriteSet并行复制

历史背景

  岁月更迭中我已经从事MySQL-DBA这个工作三个年头,见证MySQL从“基本可用”,“边缘系统可以用MySQL”,“哦操!你怎么不用MySQL”;

  正所谓!“一个数据库的境遇既取决于历史的进程,取决于它的自我奋斗!”,关于“历史的进程”在此不表,关于“自我奋斗”这里也只想谈一下

  并行复制的几个关键时间结点

  总的来说MySQL关于并行复制到目前为止经历过三个比较关键的时间结点“库间并发”,“组提交”,“写集合”;真可谓是江山代有人才出,前

  浪死在沙滩上;总的来说就后面的比前面的不知道高到哪里去了!

库间并发

  库间并发的理论依据是这样的 ---- 一个实例内可能会有多个库(schema),不同的库之间没有什么依赖关系,所以在slave那边为

  每一个库(schema)单独起一个SQL线程,这样就能通过多线程并行复制的方式来提高主从复制的效率。

  这个理论听起来没问题,但是事实上一个实例也就一个业务库,所以这种库间并发就没什么作用了;也就是说这个方式的适用场景

  比较少,针对这个不足直到“组提交”才解决!

组提交

  组提交的理论依据是这样的 --- 如果多个事务他们能在同一时间内提交,这个就间接说明了这个几个事务锁上是没有冲突的,

  也是就说他们各自持有不同的锁,互不影响;逻辑上我们几个事务看一个组,在slave以“组”为单位分配给SQL线程执行,这样

  多个SQL线程就可以并行跑了;而且不在以库为并行的粒度,效果上要比“库间并发”要好一些。

  这个事实上也有一些问题,因为它要求库上要有一定的并发度,不然就有可能变成每个组里面只有一个事务,这样就有串行没什么

  区别了,为了解决这个问题MySQL提供了两个参数就是希望在提交时先等一等,尽可能的让组内多一些事务,以提高并行复制的效率。

  “binlog_group_commit_sync_no_delay_count” 设置一个下水位,也就是说一个组要凑足多少个事务再提交;为子防止永远也凑不足

  那么多个事务MySQL还以时间为维度给出了另一个参数“binlog_group_commit_sync_delay”这个参数就是最多等多久,

  超过这个时间长度后就算没有凑足也提交。

  

  亲身经历呀! 这两个参数特别难找到合的值,就算今天合适,过几天业务上有点变化后,又可能变的不合适了;如果MySQL能自己

  达到一个自适应的效果就好了;这个自适用要到WriteSet才完成(WriteSet并不是通过自动调整这两个参数来完成,

  它采用了完全不同的解决思路)。

WriteSet

  WriteSet解决了什么问题?当然是解决了“组提交”的问题啦! 说了和没说一个样,好下面我们来举个例子(比较学院派);假设你第一天

  更新了id == 1 的那一行,第二天你更新了id == 2 的那一行,第三天有个slave过来同步你的数据啦! 以“组提交”的尿性,这两个更新

  会被打包到不同的“组”,也就是说会有两个组;由于每个组内只有一个事务,所以逻辑上就串行了,起来!

  身为DBA的你一可以看出来这两个事实上是可以打包到同一个组里来的,因为他们互不冲突,就算打包到同一个组也不引起数据的不

  一致。 于是你有两个办法

  办法1): 妹妹你大胆的把“binlog_group_commit_sync_no_delay_count”设置成 2,也就是说一个组至少要包含两个事务,并且把

  “binlog_group_commit_sync_delay”设置成24小时以上!如果你真的做了,你就可以回家了,你的数据库太慢了(第一条update等了一天),

  才完成!

  办法2): 叫MySQL用一本小本子记下它最近改了什么,如果现在要改的数据和之前的数据不冲突,那么他们就可以把包到同一个组;还是

  我们刚才的例子,由于第二天改的值的id==2所以它和第一天的不冲突,那么它完全可以把第二天的更新和第一天的更新打包到同一个组。

  这样组里面就有两个事务了,在slave第三天回放时就会有一种并行的效果。

  这本小本子这么牛逼可以做大一点吗?当然!binlog_transaction_dependency_history_size 这个参数就小本子的容量了;那我的MySQL

  有这本小本子吗? 如果你的mysql比mysql-5.7.22新的话,小本子就是它生来就有的。

  也就是说“WriteSet”是站在“组提交”这个巨人的基础之间建立起来的,而且是在master上做的自“适应”打包分组,所以你只要在master上

  新增两个参数

binlog_transaction_dependency_tracking  = WRITESET                 #    COMMIT_ORDER
transaction_write_set_extraction        = XXHASH64

  理论说完了,下面我们看一下实践。

  

  

  

  

----

原文地址:https://www.cnblogs.com/JiangLe/p/9650728.html

时间: 2024-08-01 00:19:39

谈谈MySQL的WriteSet并行复制的相关文章

MySQL 5.7 并行复制实现原理与调优

MySQL 5.7并行复制时代 众所周知,MySQL的复制延迟是一直被诟病的问题之一,然而在Inside君之前的两篇博客中(1,2)中都已经提到了MySQL 5.7版本已经支持“真正”的并行复制功能,官方称为为enhanced multi-threaded slave(简称MTS),因此复制延迟问题已经得到了极大的改进,甚至在Inside君所在的网易电商应用中已经完全消除了之前延迟长达几小时的问题.然而,Inside君发现还是有很部分小伙伴不了解这个足以载入史册的“伟大”的特性,故作分享.总之,

MySQL 5.7 并行复制

一.缘由: 某天看到主从复制延时的告警有点频繁,就想着是不是彻底可以解决一下. 一般主从复制,有三个线程参与,都是单线程:Binlog Dump(主) ----->IO Thread (从) -----> SQL Thread(从).复制出现延迟一般出在两个地方 1)SQL线程忙不过来(可能需要应用数据量较大,可能和从库本身的一些操作有锁和资源的冲突:主库可以并发写,SQL线程不可以:主要原因) 2)网络抖动导致IO线程复制延迟(次要原因). 二.解决办法: MySQL从5.6开始有了SQL

InnoSQL/MySQL并行复制的实现与配置

InnoSQL/MySQL并行复制的实现与配置 http://www.innomysql.net/article/6276.html 并行复制之前的解决方案 InnoSQL在5.5.30-v4版本中支持了从机并行复制的功能.总所周知,MySQL数据库slave服务器延迟的现象是非常普遍的,这导致了虽然对比Oracle.Microsoft SQL Server,MySQL复制允许从机进行SELECT操作,但是在实际线上环境下,由于从机延迟的关系,很难将读取操作转向到从机.这就导致了有了以下一些潜规

mysql 并行复制

并行复制,主要是解决sql_thread在高并发环境下,存在性能瓶颈.mysql5.7并行复制的思想简单易懂,一个组提交的事务都是可以并行回放,因为这些事务都已进入到事务的prepare阶段,则说明事务之间没有任何冲突(否则就不可能提交). 为了兼容MySQL 5.6基于库的并行复制,5.7引入了新的变量slave-parallel-type,其可以配置的值有: (1)DATABASE:默认值,基于库的并行复制方式 (2)LOGICAL_CLOCK:基于组提交的并行复制方式 操作步骤: 数据库版

详解mysql复制机制--异步复制,半同步复制和并行复制

详解MySQL复制机制--异步复制,半同步复制和并行复制 **# 异步复制 异步复制是MySQL自带的最原始的复制方式,主库和备库成功建立复制关系后,在备库上会有一个IO线程去主库拉取binlog,并将binlogx到本地,就是下图中Relaylog,然后备库会开启另外一个SQL线程取回放Relay log,通过这种方式达到Master-Slave数据同步的目的. 通常情况下,slave是只读的,可以承担一部分读流量,而且可以根据实际需要,添加一个或者多个slave,这样在一定程度上可以缓解主库

关于 WriteSet 对复制延迟的改进

一.复制延迟的现象问题 说到复制延迟.我曾经(现在也是)眼睁睁的看着每天好几封告警邮件,有一半是来自复制延迟,却又奈何不了.估计很多 MySQL DBA也是对他恨到牙痒痒. 二.MySQL官方给出的解决方案 2.1  5.6 --> 基于库级别的并行复制 MySQL中可能会有多个库,不同的库之间可能没有什么关系,所以在slave那边为每一个库分配了一个线程.以此提高复制的效率.也有可能会出现跨库的情况,当出现这种情况,也就这能等待这个事务完成 2.2  5.7 --> 基于组提交的并行复制 组

高性能Mysql主从架构的复制原理及配置详解

1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取的最后一次成功更新的位置.从服务器接收

高性能Mysql主从架构的复制原理及配置详解(转)

温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取

转:高性能Mysql主从架构的复制原理及配置详解

温习<高性能MySQL>的复制篇. 1 复制概述 Mysql内建的复制功能是构建大型,高性能应用程序的基础.将Mysql的数据分布到多个系统上去,这种分布的机制,是通过将Mysql的某一台主机的数据复制到其它主机(slaves)上,并重新执行一遍来实现的.复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器.主服务器将更新写入二进制日志文件,并维护文件的一个索引以跟踪日志循环.这些日志可以记录发送到从服务器的更新.当一个从服务器连接主服务器时,它通知主服务器从服务器在日志中读取