春节大放送|mysql MGR开篇

在上文书《GTID真的来了》开篇中提到了MGR，这一比较烫手的技术，趁着春节来临，这大好时光也不能就这么浪费了，咱来一小段相关内容，也入入门。

近来看bug列表，该项内容依然火得很，不管是5.7版本还是8.0版本，在我鼓捣了一段时间后，觉得这玩意确实该火，技术角度讲，采用了保证强一致性的Paxos算法（关于这个算法，网上有很多介绍，论文有，通俗易懂的也有），所以基因里就带了数据一致性以及高可用，从此可以脱胎换骨，扬眉吐气了，什么PXC（基于Galera，Percona出品，当时也是风光一时），什么异步复制，半同步，统统弱爆了，从性能角度讲，按理说强一致性下，性能有损耗是必然的，但这货比PXC高出了一大截，具体怎么形容呢，这么说吧，姚明大家都知道吧，大高个，打篮球的，郭敬明大家应该也有所耳闻，经常出现在相声台词里。  后边就不用我补充了吧，各位尽情脑补。

另外，跟传统的异步复制比也仅仅稍逊一筹，可这两个完全不是一个量级的东东哈，所以MGR即便现在你不用，了解一哈，还是很有必要的。

下面开始入正题了，不过这个MGR还是挺有内容的，为了更好的理解后边的内容，不给你造成太大困扰，咱先简单说下这个东西是什么，不然上来就一个大肘子，怕给你噎着了。

上图喽，下边是官档上的截图，此处插播一句，问最好的技术文档在哪里？答：官档。其余的技术文章和书籍只是会帮助你更好的理解，仅此而已，当然这还得是选对了，如果碰到错误信息，那就引你入歧途。

从上图可以知道，所谓的MGR其实就是一个Plugin，不过可别小瞧了这个，这次咱就来聊聊它。既然是Plugin，那就和它的兄弟们用法没多大差别，用之前install，然后就是一组参数，设置好参数后就可以使用了。从使用上来看，还是相当便利的，也没有多少复杂的配置，开启集群，加入、剔除节点都很方便，良好的继承了MySQL的优点，所以从配置运维角度讲就很亲民。Nice 

MGR提供了很多API，供上层MySQL来调用，所以从上往下，先是加入集群/维持集群需要的上层组件，比如Applier，Recovery等，下边的Replication Protocol Logics负责处理冲突检测，接收和传播事务，再下边是GCS API，用于构造复制状态机，最后一层就是负责组的通讯，Paxos就在这里。所以从这个图可以看出MGR构造了一个分布式状态机。

再来一组对比图，以下是异步复制、半同步、组复制的事务执行分发的简易图，从该图也可以估计下哪个性能好，哪个性能会受什么影响，当然大家都是聪明的小伙伴，异步复制性能最好，这个毫无疑问，半同步和组复制这个最好用事实说话，实际下来，两者差距还是比较大的，半同步会弱很多，有兴趣的话，大家可以自行测试，希望有更多同学能留言给出相关对比数据。欢迎一起探讨。

当然，这个技术毕竟是个大招，所以有点点局限也是可以理解的，技术初期有些bug也是正常的，大家用的过程也不能肆无忌惮，相信问题会一点点的被解决，首先就是要浏览官方文档的提示，里边写的很清楚，哪些是受限的，有哪些前提，我就不一一列举了，那样也没意思，但下边会写一些测试过程发现的问题以及影响，算是一些提醒吧。

因为测试场景很多，有些话题可能需要一篇单独的话题来介绍，所以后续也会推出续篇，大家先不要着急哈，你只要持续关注公众号就好了。 

崔春华

先来个多主环境中死锁场景玩玩，大家high起来啊

崔春华

PXC下的死锁（之一）会不会发作？

为什么又提到了PXC呢，因为这也是MySQL下的多主方案，火爆一时，但因为其自身弱点（本来想说特点的，但我觉得这个更贴切），此次的MGR也具有多主方案，所以这两个还挺相似的。

Step1  Primary 211 持续加载数据；

Step2  Primary 211新建session1 执行 lock table write，之后开始出现meta lock；

Step3  Primary 211新建session2 执行 rename table，出现wait，等待 meta lock；

Step4 Primary 211 在session1, 执行 drop table；

Step4 继续drop table，将lock的3个表drop完成后，锁不再出现。

没有形成死锁，成功避免Galera的死锁问题。

以上只是一次对比，不代表MGR在多主环境下可以优雅的支持DDL与DML并发，实际上就目前的这两个多主方案来讲，在这方面还是都存在其问题的，接下来就等续篇内容喽。

崔春华

小伙伴坐好，后续持续更新推出新篇章，敬请关注

欢度中国年

读码上万行

下键如有神

扫码关注