如何领会 mysql5.中的并行复制
发布时间：2021-12-20 10:33:09 所属栏目：通讯 来源：互联网
导读：如何理解 mysql5.中的并行复制，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。 一 、 前言 在 5.5以及5.5版本之前，复制流程图如下： 如何理解 mysql5.中的并行复制 流程： ① 主库dump
|
如何理解 mysql5.中的并行复制，相信很多没有经验的人对此束手无策，为此本文总结了问题出现的原因和解决方法，通过这篇文章希望你能解决这个问题。 一 、 前言 在 5.5以及5.5版本之前，复制流程图如下： 如何理解 mysql5.中的并行复制 流程： ① 主库dump thread 发现binlog有更新，则向 slave 的 IO thread 推送相应的 binlog events ② slave 的 IO thread 在接收到 master新产生的events 之后 ，写入到自己的 relay log 中。 ③ slave 的 SQL thread 开始应用 relay log，执行相应的更新语句 弊端： ① master 在多个连接 并发的写入的情况下， slave 仅仅只有一个 sql thread 进行更新，会严重的造成主从延迟 二 、 并发复制 官方称之为enhanced multi-threaded slave（简称MTS），在官方 mysql5.6 版本出现之前 ， 阿里就有人实现过 slave 的并发复制的功能，按照粒度分为 database ， table ，row 的。这里我们主要讲官方版本。 1> mysql5.6基于 database 的并行复制 通过 slave_parallel_workers=n 来设置并发复制的worker线程数量 流程： ① 主库dump thread 发现binlog有更新，则向 slave 的 IO thread 推送相应的 binlog events ② slave 的 IO thread 在接收到 master新产生的events 之后 ，写入到自己的 relay log 中。 ③ slave 的 coordinator thread 根据 binlog events 的 database 进行hash 调度分配给 worker thread ④ worker 线程 执行相应的 更新语句，互不影响 分析： ① 实现了对database 的并行复制，在多库更新的情况下slave的写入提升明显，但若是master主要在某个database更新的话则此并行复制比较鸡肋 2> mysql5.7基于 database/logical_clock 的并行复制 新添参数 slave_parallel_type=DATABSE/LOGICAL_CLOCK 设定并行复制的方式，其中database跟5.6一样，我们这里讨论下为 LOGICAL_CLOCK的模式 原理： 通过 在 master提交分为两个阶段 prepare 和 commit , 同时 prepare 的 事物标记相同的 last_commited(为当前最近一次提交事务的 seq num) 。commit 的时候给相应的事务标记 sequence num(依次递增)来实现，这些组提交的信息记录在GTID中。 流程 ： ① 主库dump thread 发现binlog有更新，则向 slave 的 IO thread 推送相应的 binlog events ② slave 的 IO thread 在接收到 master新产生的events 之后 ，写入到自己的 relay log 中。 ③ slave 的 coordinator thread 把 binlog events 中相同的 last_commited 的进行分配给 worker thread ④ worker 线程 执行相应的 更新语句，互不影响 , 对于每个事务 ，其中seq=n 的执行完毕之后 ， last_commited=n 的便可以执行了。 这里 已经几乎跟 master的 并发操作一样了，所以对于slave 来说这种基于 组提交的 并发复制已经达到了 master的并发度 举例： 如何理解 mysql5.中的并行复制 第一个数字为 last_commited , 第二个数字为 seq num slave 上执行的顺序为 ① trx1 trx2 trx3 ② trx4 ③ trx5 trx6 ④ trx7 其中，trx1 执行完毕 便可以执行 trx4 ;trx2执行完毕 便可以执行 trx5 trx6; trx5执行完毕 便可以执行trx7. PS：对于是否开启 GTID 进行了一番测试( 针对从库设置 slave_parallel_type= LOGICAL_CLOCK的情况 ) 1> 5.6 --> 5.6 基于 database 的并行复制 没有问题 2> 5.7 --> 5.7 ① 开启GTID 的情况下，将组提交的 last_commited 和 seq num等信息记录到 GTID 中； ② 未开启 GTID 的情况下 mysql5.7会 在每次提交events之前 set gtid_next='annonymous'，因此会产生一个annonymous_gtid ,然后将组提交的 last_commited 和 seq num等信息记录下来 ，可以实现并行复制。 3> 5.6 --> 5.7 ① 未开启 GTID 的情况下 ，mysql5.6 作为master 并不会 进行 set gtid_mode='annonymous' 操作，故而不会有last_commited 和 seq num ，mysql5.7 slave的并行复制设置失效(实际单线程执行更新语句)，不会报错。 ② 开启 GTID 的情况下，倘若 master没有并发事务，并行复制设置失效(实际单线程执行更新语句)，则复制不报错；若有并发事务，则复制直接出错，内容如下图(意思是 5.6的格式的events 到了5.7这里在设置 logical_clock的情况下无法识别) 如何理解 mysql5.中的并行复制 以上 在 slave_parallel_type=DATABASE的情况下没有问题。 综上，不要在 5.6--->5.7的同步中开启 logical_clock 模式的并行复制 看完上述内容，你们掌握如何理解 mysql5.中的并行复制的方法了吗？如果还想学到更多技能或想了解更多相关内容，欢迎关注亿速云行业资讯频道，感谢各位的阅读！ （编辑：淮北站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
站长推荐
热点阅读