Mysql读写分离与高可用架构设计

两主多从架构图

两主多从架构说明

1. 数据库之间做主从复制，实现双主多备
2. 在数据库之间利用mysql-mmm套件实现HA，并用monitor进行监听
3. 利用amoeba进行读写分离
4. 利用keepalived实现amoeba的HA
5. 利用keepalived实现mysql-mmm的monitor的HA

虚拟IP
master 192.168.31.201
read 192.168.31.202，192.168.31.203
monitor 192.168.31.204
amoeba 192.168.31.205
真实IP
master1 192.168.31.210
master2 192.168.31.211
slave1 192.168.31.212
slave1_backup 192.168.31.213
slave2 192.168.31.214
slave2_backup 192.168.31.215
monitor1 192.168.31.216
monitor2 192.168.31.217
amoeba1 192.168.31.218
amoeba2 192.168.31.219

各个模块之间通过Virtual IP进行访问，屏蔽单点故障的影响，amoeba通过MMM提供的virtual IP找到amoeba中配置的读写数据库地址。

mysql-mmm

Mysql-MMM是Master-Master Replication Manager for MySql（mysql主主复制管理器的简称），适用于对数据一致性要求不是很高的环境，它完全实现了真正的高可用。

mysql自身提供了AB复制的功能，可以通过配置各自的my.cnf来实现：Master-Master的主-主双向复制策略，而且还可以为任意Master配备一个slave备库，从而实现对Master实现主-主备份以及主-从备份。假设有两个Master，正常情况下只有一个master对外开放（记为master），当这个对外服务的master宕机了，这时mysql本身并不具备failover切换能力，尽管还有一个master的可用备份（记为master_backup）。所以这种方案只是实现了冷备份，但是没有实现热备。为了真正实现热备，mysql-mmm应时而生。（其实也可以用keepalived实现，但是当实现两主多从架构的时候，keepalived并不能保证slave的master 会切换到master_backup上）

Mysql-MMM旨在用来监控mysql主主复制和做失败转移。其原理是将真实数据库节点的IP映射为虚拟机IP集，在这个虚拟的IP集中，有一个用于write的IP，多个用于read 的IP，这个用于write的虚拟IP映射着数据库节点中的两台master(一个为主动，一个为被动)的真实IP，以此来实现failover的切换，read IP对应着slave节点（并不对应着读写分离，读写分离还是由amoeba来实现），最好的理解方式就是把write IP和read IP对应着master节点集和slave节点集合。通过virtual IP实现后台故障对客户端是透明无感的。

keepalived

也是通过虚拟IP映射的方法来解决单点失败的问题，keepalived在可以用来解决master单点故障 ，但是在本框架中keepalived用于实现MMM-monitor和amoeba代理的高可用，通过脚本来周期性判断服务是否正常运行，如果发现服务异常，就会修改虚拟IP绑定的monitor，将其修改为monitor_backup，所以对集群的监控服务时可用的。

amoeba

mysql官方实现并维护了一款读写分离的工具mysql-proxy，但是由于这个工具还不太成熟，没有在生产环境中真正使用过。取而代之的是amoeda，这是淘宝开源的一款mysql读写分离的工具，基于java开发，通过xml配置。Amoeba相当于一个SQL请求的路由器，它集中地响应应用的请求，依据用户事先设置的规则，将SQL请求发送到特定的数据库上执行。基于此可以实现负载均衡、读写分离、高可用性等需求。（本身不提供，结合mysql Replication进行组合）

安装及配置参考如下博客
http://blog.itpub.net/8078021/viewspace-768221/
http://code727.iteye.com/blog/2249677
http://blog.csdn.net/whb123andy/article/details/49247811