MYSQL 在非互联网企业中的读写分离架构探索

Posted 2021-05-02 AustinDatabases

当前浏览器不支持播放音乐或语音，请在微信或其他浏览器中播放

(原创上面的作者变成了 carol11,是赞赏的账号，不是作者本人，作者没变)

mysql的高可用和使用大多都是基于互联网的方式，MHA，PXC，这些方式在互联网里面大量的使用，并且使用的非常好，互联网企业充斥着各种修改MYSQL 原代码的“高端人才”。 

反观，为什么传统企业，金融企业使用MYSQL，并让这个数据库发扬光大的缺失凤毛菱角。

抛出去互联网企业敢给钱，敢雇人，做什么都可以在做中碰钉子，在改善的基本思想。大量的支持和维护运维的力量是不可以忽视的。

传统企业在这方面是差的比较远，所以MYSQL这样的数据库用的不顺手，在加上业务的紧密和开发方式等等 bulabula . MYSQL 的架构在使用了上面那些企业给运维带来很多不便。

个人认为（也许需要继续改善），传统企业或者金融企业需要的MYSQL的架构好维护，好使用，更要妥协开发的传统业务的某些方式。

你可以使用ORACLE  RAC ，Dataguard, SQL SERVER 的  Cluster ,  Always-on 等等，至少在读写分离上或高密集的操作中，基本上不会给你太尴尬的表现。  MYSQL 以前一直是主从复制，而要保证主从复制的一致性，除了用半同步这样的“单条虎”，然后就是各种开发要求，要支持互联网动辄几百人甚至上千人的开发团队是有技术力量来将那些密集型的操作去化解的。而传统企业没有那么多的资金来雇佣那么多的开发人员，运维人员。

一个可靠的MYSQL架构就显得尤为重要了，目前MGR 作为MYSQL的复制或者说高可用的方式，已经推开。当然也有问题，但至少他能给你做到的，1 数据的一致性 2 搭建方式的简单  3维护方式相对其他方式要简单，配上可靠的中间件，基本上传统的开发人员就可以实现他们想要的读写分离，以及运维人员需要的FAILOVER ，及对应用程序的透明切换。

那还是来点实际的，下面是一MYSQL高可用加读写分离的架构图

其实中间件使用哪个可能无所谓，但为了更好的简化运维的工作，我们其实可以使用DOCKER 来将中间件容器化，这样能降低中间件的FAILOVER的工作量，同时也能节省资源（通常传统企业的访问量不大）。架构中还有一点估计是有人想 challange的， 就是为什么要用两个中间件，说实话可以不用，一个中间件就可以，但两个的中间件也是考虑传统企业的开发人员，你要他完全将所有的 SELECT 语句 都走从库，这对他本身来说也是一项挑战，其中的问题也会不少，这边两个中间件，就是给运维和开发一个缓冲。如果想进行在写库的操作那就走 一个中间件，如果想仅仅是只读的方式使用，则去访问另一个走只读的中间件即可，对开发和运维都还算比较友好。

这样既能满足迁就传统企业开发和运维的LEVEL 也能更简单的批量定制化的部署。同时对于应用也是透明的切换（standby -- primary）

可能还有人问，中间件为什么不复用，多套MGR 用一个中间件做FAILOVER 不也是OK ，其实是可以的，但如果使用了DOCKER 的情况下，其实分开更好，一套MGR 用自己的，这样降低耦合，出了问题也不是大面积性的，只会影响相关的对应的MGR。

1  正常的状态

2  主节点故障切换状态

3  切换后的状态

剩下的就是落实DOCKER 中间件的部署以及DOCKER FAILOVER的问题了，这就得麻烦运维的同学了。

最后中间件用的啥，打个赏吧