Mysql常用4大架构案例

4大经典架构

mysql不是分布式存储，所以对于大数据量的存储使用其他数据库进行扩展，怎么部署网上一大堆，这里只是说下这些架构的区别，提供一个参考方案。

Mysql-keeplive架构

DB1，DB2看做一台mysql，利用2台mysql master上的keeplive的vip地址暴露给Web Server进行数据读写。
这里要说下，主从复制是利用binlog二进制日志实现的，这个架构是比较常用的。

好处：简单，实用，对外的vip就一个地址，所以不会出现往2台同时写入的情况。
坏处1：Keeplive的网络环境要稳定，不然出现脑裂或者地址飘来飘去的。
坏处2：同步信息记录在数据库中，一旦出现数据错误，会导致同步信息不一致。

Mysql-MMM架构

MMM代表：2个master，一个monitor，他原理和keeplive差不多，只是他的检测是独立的，通过第三方 Monitor来判断，来把控对外地址的该给哪一个，这样一定程度上防止脑裂，也是一样网络要稳定。

好处1：由Monitor把控对外地址，对外提供2个地址，一个读写，一个只读。
好处2：同步进度信息保存在Monitor上，这样更准确数据信息一致性。
好处3：常用于读写分离。
坏处：没想到，都是经典架构也用了很多年了。

Mysql-Heatbeat/SAN架构

这个比较经典，为了防止数据不一致的情况，提高I/O吞吐量，通过心跳来启动脚本挂载VIP和磁盘对外提供服务，这个相当于应用的主备，实现服务进程跷跷板。

好处：在应用层做到的主备。
坏处：如果出现脑裂出现同时写对于数据会有问题。

Mysql-Heatbeat/DRBD架构

Heartbeat和上面差不多，就是检测存活的，这里说下DRBD，运维的同学应该有接触过对于大容量数据通过网络同步经常用到，特点是DRBD主提供读写，DRBD备只提供只读，这样不会出现数据双写的情况，能尽可能的保证数据一致性，这个架构就是利用这个特性。

好处1：DRBD同步比较稳定。
好处2：支持大数据量的同步。
坏处：同样是会出现脑裂，这里说一下，按照架构的特性会把出问题那台通过IPMI脚本直接关机或者关闭服务，防止脑裂。

总结

在没有网络状况的情况下，这些架构还是很稳定的，在各行各业都使用了很多年了。