MySQL高可用的几种方案

xywuyiba6

　　首先我们看看MySQL高可用的几种方案：

　　对于数据实时性要求不是特别严格的应用，只需要通过廉价的pc server 来扩展Slave 的数量，将读压力分散到多台Slave 的机器上面，即可通过分散单台数据库服务器的读压力来解决数据库端的读性能瓶颈，毕竟在大多数数据库应用系统中的读压力还是要比写压力大很多。这在很大程度上解决了目前很多中小型网站的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。

　　MySQL Cluster由一组计算机构成，每台计算机上均运行着多种进程，包括MySQL服务器，NDB Cluster 的数据节点，管理服务器，以及（可能）专门的数据访问程序。NDB” 是一种“内存中”的存储引擎，它具有可用性高和数据一致性好的特点。MySQL Cluster要实现完全冗余和容错，至少需要 4台物理主机，其中两个为管理节点。MySQL Cluster使用不那么广泛，除了自身构架因素、适用的业务有限之外，另一个重要的原因是其安装配置管理相对复杂繁琐，总共有几十个操作步骤，需要DBA花费几个小时才能搭建或完成。重启 MySQL Cluster 数据库的管理操作之前需要执行 46 个手动命令，需要耗费 DBA 2.5 小时的时间，而依靠MySQL Cluster Manager只需一个命令即可完成，但MySQL Cluster Manager 仅作为商用 MySQL Cluster 运营商级版本 (CGE) 数据库的一部分提供，需要购买。其官方的说明，若应用中的SQL操作为主键数据库访问，包含一些 JOIN 操作而非对整个表执行常规扫描和JOIN而返回数万行数据，则适合Cluster，否则不合适，从这一条限制来看，表明大多数业务场景并不合适MySQL Cluster，业内有资深人士也凭评价：NDB不适合大多数业务场景，而且有安全问题。

　　heartbeat是Linux-HA工程的一个组件,heartbeat最核心的包括两个部分：心跳监测和资源接管。在指定的时间内未收到对方发送的报文，那么就认为对方失效，这时需启动资源接管模块来接管运 行在对方主机上的资源或者服务。

　　DRBD是通过网络来实现块设备的数据镜像同步的一款开源Cluster软件，它自动完成网络中两个不同服务器上的磁盘同步，相对于binlog日志同步，它是更底层的磁盘同步，理论上DRDB适合很多文件型系统的高可用。

　　Lvs是一个虚拟的服务器集群系统，可以实现LINUX平台下的简单负载均衡。keepalived是一个类似于layer3, 4 & 5交换机制的软件，主要用于主机与备机的故障转移，这是一种适用面很广的负载均衡和高可用方案，最常用于Web系统。

　　这种gluster模式可以说是全新的一种高可用方案，前面也提到其优点，它的缺点不多，不支持XA，不支持Lock Table，只能用InnoDB引擎。
Mycat高可用方案
　　Mycat作为一个代理层中间件，Mycat系统的高可用涉及到Mycat本身的高可用以及后端MySQL的高可用，前面章节所讲的MySQL高可用方案都可以在此用来确保Mycat所连接的后端MySQL服务的高可用性。在大多数情况下，建议采用标准的MySQL主从复制高可用性配置并交付给Mycat来完成后端MySQL节点的主从自动切换。

　　如图所示，MySQL节点开启主从复制的配置方案，并将主节点配置为Mycat的dataHost里的writeNode，从节点配置为readNode，同时Mycat内部定期对一个dataHost里的所有writeHost与readHost节点发起心跳检测，正常情况下，Mycat会将第一个writeHost作为写节点，所有的DML SQL会发送给此节点，若Mycat开启了读写分离，则查询节点会根据读写分离的策略发往readHost(+writeHost)执行，当一个dataHost里面配置了两个或多个writeHost的情况下，如果第一个writeHost宕机，则Mycat会在默认的3次心跳检查失败后，自动切换到下一个可用的writeHost执行DML SQL语句，并在conf/dnindex.properties文件里记录当前所用的writeHost的index（第一个为0，第二个为1，依次类推），注意，此文件不能删除和擅自改变，除非你深刻理解了它的作用以及你的目的。
　　那么问题来了，当原来配置的MySQL写节点宕机恢复以后，怎么重新加入Mycat，要不要恢复为原来的写节点？关于这个问题，我们也曾与DBA讨论很久，最终的建议方案是，保持现有状态不变，改旗易帜，恢复后的MySQL节点作为从节点，跟随新的主节点，重新配置主从同步，原先跟随该节点做同步的其他节点也同样换帅，重新配置同步源，这些节点的数据手工完成同步以后，再加入Mycat里。目前1.3版本的Mycat还没有实现监控MySQL主从同步状态的功能，因此这个过程里，DBA可以先修改MySQL的密码，让Mycat无法链接故障服务器，等同步完成以后，恢复密码，这样Mycat就自动重新将修复好的Mycat纳管进来了。
　　说完了MySQL部分，接下来我们看看Mycat自身的高可用性，由于Mycat自身是属于无状态的中间件（除了主从切换过程中记录的dnindex.properties文件），因此Mycat很容易部署为集群方式，提供高可用方案。原先有规划Mycat-balance组件，专门用于Mycat负载均衡，但由于缺乏志愿者，也没有经过生产实践验证，
　　因此暂时不建议使用，官方建议是采用基于硬件的负载均衡器或者软件方式的HAproxy，HAProxy相比LVS的使用要简单很多，功能方面也很丰富，免费开源，稳定性也是非常好，可以与LVS相媲美，根据官方文档，HAProxy可以跑满10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs (Myri-10G PCI-Express)，这个作为软件级负载均衡，也是比较惊人的，下图是HAproxy+Mycat集群+MySQL主从所组成的高可用性方案：
　　、
　　如果还担心HAproxy的稳定性和单点问题，则可以用keepalived的VIP的浮动功能，加以强化：

Galary Cluster 配置
　　Mycat1.4.1 开始支持galary cluster 集群的配置，提高心跳可用。
　　配置如下： 1.4.1 开始支持MySQL 集群模式，让读更加安全可靠，配置如下： MyCAT心跳检查语句配置为 show status like ‘wsrep%’ ， dataHost 上定义两个新属性： switchType=”3” 此时意味着开启MySQL集群复制状态状态绑定的读写分离与切换机制，Mycat心跳机制通过检测集群复制时延时，如果延时过大或者集群出现节点问题不会负载改节点。
　　 show status like ‘wsrep%’