MySQL 高可用架构在业务层面的分析研究_MySQL
前言: 相对于传统行业的相对服务时间9x9x6或者9x12x5,因为互联网电子商务以及互联网游戏的实时性,所以服务要求7*24小时,业务架构不管是应用还是数据库,都需要容灾互备,在mysql的体系中,最好通过在最开始阶段的数据库架构阶段来实现容灾系统。所以这里从业务宏观角度阐述下mysql架构的方方面面。 一,MySQL架构设计—业务分析 (1)读多写少 虚线表示跨机房部署,比如电子商务系统,一个Master既有读也有些写,对读数据一致性需要比较重要的,读要放在Master上面。 M(R)仅仅是一个备库,只有M(WR)挂了之后,才会切换到M(R)上,这个时候M(R)就变成了读写库。比如游戏系统,有很多Salve会挂载后面一个M(R)上面。 (2)读多写少MMS-电商 如果是电子商务类型的,这种读多写少的,一般是1个master拖上4到6个slave,所有slave挂载在一个master也足够了。 切换的时候,把M1的读写业务切换到M2上面,然后把所有M1上的slave挂到M2上面去,如下所示: (3)读多写少MMSS-游戏 如果是游戏行业的话,读非常多蛮明显的,会出现一般1个Master都会挂上10个以上的Slave的情况,所以这个时候,可以把一部分Slave挂载新的M(R)上面。至少会减少一些压力,这样至少服务器挂掉的时候,不会对所有的slave有影响,还有一部分在M(R)上的slave在继续,不会对所有的slave 受到影响,见图3, (4)读少写多 意味着读并不会影响写的效率,所以读写都可以放在一个M1(WR),而另外一个不提供读也不提供写,只提供standby冗余异地容灾。 这个异地容灾是非常重要的,否则如果是单机的,单边的业务,万一idc机房故障了,一般就会影响在线业务的,这种 造成业务2小时无法应用,对于在线电子商务交易来说,影响是蛮大的,所以为了最大限度的保证7*24小时,必须要做到异地容灾,MM要跨idc机房。虽然对资源有一些要求,但是对HA来说是不可缺少的,一定要有这个MM机制。 做切换的时候,把所有的读写从M1直接切换到M2上就可以了。 (5)读写平分秋色 读和写差不多,但是读不能影响写的能力,把读写放在M1(WR)上,然后把一部分读也放在M2(R)上面,当然M1和M2也是跨机房部署的。 切换的时候,把一部分读和全部写从M1切换到M2上就可以了。 |