HA solutions for MySQL

1.master-slave

通过业务实现读写分离

数据库调整需要业务修改配置

主从切换需要DBA⼿手⼯工进⾏行

2.proxy

单点写⼊入,多点 读取,从库负载均衡

中间层⾃自动屏蔽 失败节点,或进⾏行报警或切换

数据库调整对应⽤用程序透明

dbproxy本⾝身的⾼高可⽤用是个问题

中间层可能成为瓶颈

资源浪费

3.Heartbeat+DRBD

4.MMM(Multi Master Replication Manager)

monitor+agent实现监控和切换

授权和同步⽤用物理ip

应⽤用程序配置虚拟ip

M/S⾃自动切换

Monitor节点是单点，可以结合Keepalived实现高可用。

从库个数变更需要改应用配置，重发。

MMM无法完全的保证数据一致性（master变更时有可能产生）

5.pxc（Percona Xtradb Cluster）

多点写⼊入

同步复制

并⾏行复制

没有延迟

不丢数据 数据严格一致性，尤其适合电商类应用；

健康检查

服务高可用；

新节点可以自动部署，部署操作简单；

只支持InnoDB引擎；

所有表都要有主键；

不支持LOCK TABLE等显式锁操作；

锁冲突、死锁问题相对更多；

不支持XA；

集群吞吐量/性能取决于短板；

新加入节点采用SST时代价高；

存在写扩大问题；

如果并发事务量很大的话，建议采用InfiniBand网络，降低网络延迟；

6.MHA（mysql-master-ha）

优点：相比mmm方案可以自动同步差异的日志，可以自己写故障转移的脚本，比较灵活

缺点：如果故障转移了需要重新修改配置文件，重新启动masterha\_manager服务

MySQL高可用方案选型参考

http://imysql.com/2015/09/14/solutions-of-mysql-ha.shtml

MySQL 高可用架构之MMM

http://www.cnblogs.com/gomysql/p/3671896.html

MMM适用于对数据的一致性要求不是很高，但是又想最大程度的保证业务可用性的场景。

Linux 高可用（HA）集群之DRBD详解

http://freeloda.blog.51cto.com/2033581/1275384

MySQL高可用架构之MHA

https://code.google.com/p/mysql-master-ha/

http://www.cnblogs.com/gomysql/p/3675429.html

说明：copy from 美团点评 http://wiki.sankuai.com/display/~zhuwencheng/HA+solutions+for+MySQL