[转载] MySQL高可用方案选型参考

原文: http://imysql.com/2015/09/14/solutions-of-mysql-ha.shtml?hmsr=toutiao.io&utm_medium=toutiao.io&utm_source=toutiao.io

 

本次专题是 MySQL高可用方案选型，这个专题想必有不少同窗感兴趣。

高可用的意义以及各类不一样高可用等级相应的停机时间我就没必要多说了，直接进入主题。

可选MySQL高可用方案

MySQL的各类高可用方案，大可能是基于如下几种基础来部署的：

1. 基于主从复制；
2. 基于Galera协议；
3. 基于NDB引擎；
4. 基于中间件/proxy；
5. 基于共享存储；
6. 基于主机高可用；

在这些可选项中，最多见的就是基于主从复制的方案，其次是基于Galera的方案，咱们重点说说这两种方案。其他几种方案在生产上用的并很少，咱们只简单说下。

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

双节点主从 + keepalived/heartbeat

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

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

• 采用keepalived做为高可用方案时，两个节点最好都设置成BACKUP模式，避免由于意外状况下（好比脑裂）相互抢占致使往两个节点写入相同数据而引起冲突；
• 把两个节点的auto_increment_increment（自增起始值）和auto_increment_offset（自增步长）设成不一样值。其目的是为了不master节点意外宕机时，可能会有部分binlog未能及时复制到slave上被应用，从而会致使slave新写入数据的自增值和原先master上冲突了，所以一开始就使其错开；固然了，若是有合适的容错机制能解决主从自增ID冲突的话，也能够不这么作；
• slave节点服务器配置不要太差，不然更容易致使复制延迟。做为热备节点的slave服务器，硬件配置不能低于master节点；
• 若是对延迟问题很敏感的话，可考虑使用MariaDB分支版本，或者直接上线MySQL 5.7最新版本，利用多线程复制的方式能够很大程度下降复制延迟；
• 对复制延迟特别敏感的另外一个备选方案，是采用semi sync replication（就是所谓的半同步复制）或者后面会提到的PXC方案，基本上无延迟，不过事务并发性能会有不小程度的损失，须要综合评估再决定；
• keepalived的检测机制须要适当完善，不能仅仅只是检查mysqld进程是否存活，或者MySQL服务端口是否可通，还应该进一步作数据写入或者运算的探测，判断响应时间，若是超过设定的阈值，就能够启动切换机制；
• keepalived最终肯定进行切换时，还须要判断slave的延迟程度。须要事先定好规则，以便决定在延迟状况下，采起直接切换或等待何种策略。直接切换可能由于复制延迟有些数据没法查询到而重复写入；
• keepalived或heartbeat自身都没法解决脑裂的问题，所以在进行服务异常判断时，能够调整判断脚本，经过对第三方节点补充检测来决定是否进行切换，可下降脑裂问题产生的风险。

双节点主从+keepalived/heartbeat方案架构示意图见下：

图解：MySQL双节点（单向/双向主从复制），采用keepalived实现高可用架构。

多节点主从+MHA/MMM

多节点主从，能够采用一主多从，或者双主多从的模式。
这种模式下，能够采用MHA或MMM来管理整个集群，目前MHA应用的最多，优先推荐MHA，最新的MHA也已支持MySQL 5.6的GTID模式了，是个好消息。
MHA的优点很明显：

• 开源，用Perl开发，代码结构清晰，二次开发容易；
• 方案成熟，故障切换时，MHA会作到较严格的判断，尽可能减小数据丢失，保证数据一致性；
• 提供一个通用框架，可根据本身的状况作自定义开发，尤为是判断和切换操做步骤；
• 支持binlog server，可提升binlog传送效率，进一步减小数据丢失风险。

不过MHA也有些限制：

• 须要在各个节点间打通ssh信任，这对某些公司安全制度来讲是个挑战，由于若是某个节点被黑客攻破的话，其余节点也会跟着遭殃；
• 自带提供的脚本还须要进一步补充完善，固然了，通常的使用仍是够用的。

多节点主从+etcd/zookeeper

在大规模节点环境下，采用keepalived或者MHA做为MySQL的高可用管理仍是有些复杂或麻烦。
首先，这么多节点若是没有采用配置服务来管理，必然杂乱无章，线上切换时很容易误操做。
在较大规模环境下，建议采用etcd/zookeeper管理集群，可实现快速检测切换，以及便捷的节点管理。

基于Galera协议的高可用方案

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

PXC的架构示意图见下：

(图片源自网络)，图解：在底层采用wsrep接口实现数据在多节点间的同步复制。

 

(图片源自网络)，图解：在PXC中，一次数据写入在各个节点间的验证/回滚流程。

PXC的优势

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

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

• 只支持InnoDB引擎；
• 全部表都要有主键；
• 不支持LOCK TABLE等显式锁操做；
• 锁冲突、死锁问题相对更多；
• 不支持XA；
• 集群吞吐量/性能取决于短板；
• 新加入节点采用SST时代价高；
• 存在写扩大问题；
• 若是并发事务量很大的话，建议采用InfiniBand网络，下降网络延迟；

事实上，采用PXC的主要目的是解决数据的一致性问题，高可用是顺带实现的。由于PXC存在写扩大以及短板效应，并发效率会有较大损失，相似semi sync replication机制。

其余高可用方案

• 基于NDB Cluster，因为NDB目前仍有很多缺陷和限制，不建议在生产环境上使用；
• 基于共享存储，一方面须要不太差的存储设备，另外共享存储可也会成为新的单点，除非采用基于高速网络的分布式存储，相似RDS的应用场景，架构方案就更复杂了，成本也可能更高；
• 基于中间件(Proxy)，如今可靠的Proxy选择并很少，并且没有通用的Proxy，都有有所针对，好比有的专一解决读写分离，有的专一分库分表等等，真正好用的Proxy通常要自行开发；
• 基于主机高可用，是指采用相似RHCS构建一个高可用集群后，再部署MySQL应用的方案。老实说，我没实际用过，但从侧面了解到这种方案生产上用的并很少，可能也有些局限性所致吧；

以DBA们的聪明才智，确定还有其余我不知道的方案，也欢迎同行们间多多交流。