MySQL高可用方案

MySQL高可用方案

生产环境中最常见的就是基于主从复制的方案，其次是基于Galera的方案

其次看对数据一致性的要求

对数据一致性要求较高的建议是基于Galera的PXC

尽可能减少数据丢失的建议MHA

允许丢一些数据的可以使用mysql + keepalived 

基于主从复制的高可用方案

双节点主从 + keepalived

一般来说，中小型规模的时候，采用这种架构是最省事的。
两个节点可以采用简单的一主一从模式，或者双主模式，并且放置于同一个VLAN中，在master节点发生故障后，利用keepalived的高可用机制实现快速切换到slave节点

在这个方案里，有几个需要注意的地方：

* 采用keepalived作为高可用方案时，两个节点最好都设置成BACKUP模式，避免因为意外情况下（比如脑裂）相互抢占导致往两个节点写入相同数据而引发冲突；

* slave节点服务器配置不要太差，否则更容易导致复制延迟。作为热备节点的slave服务器，硬件配置不能低于master节点；

* 如果对延迟问题很敏感的话，利用多线程复制的方式可以很大程度降低复制延迟；

* keepalived的检测机制需要适当完善，不能仅仅只是检查mysqld进程是否存活，或者MySQL服务端口是否可通，还应该进一步做数据写入或者运算的探测，判断响应时间，如果超过设定的阈值，就可以启动切换机制；

* keepalived最终确定进行切换时，还需要判断slave的延迟程度。需要事先定好规则，以便决定在延迟情况下，采取直接切换或等待何种策略。直接切换可能因为复制延迟有些数据无法查询到而重复写入；

* keepalived自身无法解决脑裂的问题，因此在进行服务异常判断时，可以调整判断脚本，通过对第三方节点补充检测来决定是否进行切换，可降低脑裂问题产生的风险。

MHA高可用方案

原理

（1）从宕机崩溃的master保存二进制日志事件（binlog events）;

（2）识别含有最新更新的slave；

（3）应用差异的中继日志（relay log）到其他的slave；

（4）应用从master保存的二进制日志事件（binlog events）；

（5）提升一个slave为新的master；

（6）使其他的slave连接新的master进行复制；

MHA的优势很明显：

方案成熟，故障切换时，MHA会做到较严格的判断，尽量减少数据丢失，保证数据一致性；

提供一个通用框架，可根据自己的情况做自定义开发，尤其是判断和切换操作步骤；

支持binlog server，可提高binlog传送效率，进一步减少数据丢失风险。

不过MHA也有些限制：

需要在各个节点间打通ssh信任，这对某些公司安全制度来说是个挑战，因为如果某个节点被攻破的话，其他节点也会跟着遭殃；

自带提供的脚本还需要进一步补充完善，当然了，一般的使用还是够用的。

基于Galera协议的高可用方案

Galera是Codership提供的多主数据同步复制机制，可以实现多个节点间的数据同步复制以及读写，并且可保障数据库的服务高可用及数据一致性。
基于Galera的高可用方案主要有MariaDB Galera Cluster和Percona XtraDB Cluster（简称PXC），目前PXC用的会比较多一些。

PXC的优点

服务高可用；
数据同步复制(并发复制)，几乎无延迟；
多个可同时读写节点，可实现写扩展，不过最好事先进行分库分表，让各个节点分别写不同的表或者库，避免让galera解决数据冲突；
新节点可以自动部署，部署操作简单；
数据严格一致性，尤其适合电商类应用；
完全兼容MySQL；

虽然有这么多好处，但也有些局限性：

只支持InnoDB引擎；
所有表都要有主键；
不支持LOCK TABLE等显式锁操作；
锁冲突、死锁问题相对更多；
不支持XA；
集群吞吐量/性能取决于短板；
新加入节点采用SST时代价高；
存在写扩大问题；
如果并发事务量很大的话，建议采用InfiniBand网络，降低网络延迟；
事实上，采用PXC的主要目的是解决数据的一致性问题，高可用是顺带实现的。因为PXC存在写扩大以及短板效应，并发效率会有较大损失，类似semi sync replication机制。

容忍少量的数据丢失以及成本的问题的角度上建议 keepalived+mysql高可用方案