(转)MySQL高可用解决方案

MySQL高可用解决方案

原文：http://www.ywnds.com/?p=5565

有这么两个概念，数据库的可靠性和数据库的可用性，可靠性指的是数据可靠，而可用性指的是服务可用。但是不管是可靠性还是可用性都没有绝对的，所以可用性方面也就有这么一些等级标准，如:

90%一年内可接受最高36天服务不可用

99%一年内可接受最高3.65天服务不可用

99.9%一年内可接受最高8.76小时服务不可用

99.99%一年内可接受最高52.56分钟服务不可用

99.999%一年内可接受最高5.26分钟服务不可用

根据需求做等级选择，一般等级需求越高那么所要付出的费用也是越贵的。一般像银行系统都是追求数据的可靠，而像互联网行业都是需要服务的可用。

MySQL高可用方案图

总结来说大概有这么几种方案：MySQL Replication，HA-software SAN，HA-software DRBD，MySQL NDB Cluster，Tungsten Replicator，MariaDB Galera。

MySQL Replication

基于MySQL复制做高可用，但MySQL本身没有提供Replication Failover的解决方案，也就是说需要在MySQL复制的基础上借助第三方软件来做到MySQL高可用。借助于MySQL复制做高可用在MySQL5.7之前都会有一个问题就是复制延迟，不能保证数据的一致性（可以借助percona toolkit做数据一致性检测）。MySQL5.7引入可以做到基于表的多线程复制技术，所以在延迟方面会很大的改进。

MySQL Replication默认异步，当master崩溃时，很有可能一些slave还没有接受最新的relay log events，这意味着每一个slave都相互处在不同的状态。但Semi-Synchronous Replication，半同步复制大大降低了binlog event仅仅存在于崩溃master上的这种风险。这非常有用的能避免数据丢失。但是半同步不能解决所有一致性问题，只能保证一个（不是所有）slave接受到master端的commit的binlog events，其他slave也许还没有接受全部的binlog events。不能apply不同的binlog events 从新的slave到 其他slave上，也不能保证相互一致性。

基于复制的高可用有预热的好处，也就是说当从一个节点转移到另外一个节点时，不用再重新载入数据，MySQL数据一般都是存在内存中的。

MySQL MHA

MHA是一位日本MySQL大牛用Perl写的一套MySQL故障切换方案，来保证数据库系统的高可用，在宕机的时间内（通常10—30秒内），完成故障切换，部署MHA，可避免主从一致性问题，节约购买新服务器的费用，不影响服务器性能，易安装，不改变现有部署。还支持在线切换，从当前运行master切换到一个新的master上面，只需要很短的时间（0.5-2秒内），此时仅仅阻塞写操作，并不影响读操作，便于主机硬件维护。

在有高可用，数据一致性要求的系统上，MHA 提供了有用的功能，几乎无间断的满足维护需要。

优点：

1）Master自动监控和故障转移

在当前已存在的主从复制环境中，MHA可以监控master主机故障，并且故障自动转移。即使有一些slave没有接受新的relay log events，MHA也会从最新的slave自动识别差异的relay log events，并apply差异的event到其他slaves。因此所有的slave都是一致的。MHA秒级别故障转移（9-12秒监测到主机故障，任选7秒钟关闭电源主机避免脑裂，接下来apply差异relay logs，注册到新的master，通常需要时间10-30秒即total downtime）。另外，在配置文件里可以配置一个slave优先成为master。因为MHA修复了slave之间的一致性，dba就不用去处理一致性问题。

当迁移新的master之后，并行恢复其他slave。即使有成千上万的slave,也不会影响恢复master时间，slave也很快完成。

2）非交互式故障转移

非交互式的故障转移也提供（不监控master，自动故障转移）。这个特性很有用，特别是你已经安装了其他软件监控master。比如，用Pacemaker(Heartbeat)监测master故障和vip接管，用MHA故障转移和slave提升。

3）在线切换master到不同主机

在很多情况下，有必要将master转移到其他主机上（如替换raid控制器，提升master机器硬件等等）。这并不是master崩溃，但是计划维护必须去做。计划维护导致downtime，必须尽可能快的恢复。快速的master切换和优雅的阻塞写操作是必需的，MHA提供了这种方式。优雅的master切换， 0.5-2秒内阻塞写操作。在很多情况下0.5-2秒的downtime是可以接受的，并且即使不在计划维护窗口。这意味着当需要更换更快机器，升级高版本时，dba可以很容易采取动作。

4）master crash不会导致主从数据不一致性

当master crash后，MHA自动识别slave间relay logevents的不同，然后应用与不同的slave，最终所有slave都同步。结合通过半同步一起使用，几乎没有任何数据丢失。

5）MHA部署不影响当前环境设置

MHA最重要的一个设计理念就是尽可能使用简单。使用与5.0+以上主从环境，其他HA方案需要改变mysql部署设置，MHA不会让dba做这些部署配置，同步和半同步环境都可以用。启动/停止/升级/降级/安装/卸载 MHA都不用改变mysql主从（如启动/停止）。

当你需要升级MHA到新版本时，不需要停止MySQL，仅仅更新HMA版本，然后重新启动MHAmanger即可。

MHA支持包含5.0/5/1/5.5(应该也支持5.6，翻译文档时MHA开发者没更新对于5.6版本)。有些HA方案要求特定的mysql版本（如mysqlcluster，mysql with global transaction id 等）,而且你可能不想仅仅为了MasterHA而迁移应用。很多情况下，公司已经部署了许多传统的mysql应用，开发或dba不想花太多时间迁移到不同的存储引擎或新的特性（newer bleeding edge distributions 不知道这个是否该这么翻译）。

MySQL MMM

MMM即Master-Master Replication Manager for MySQL（mysql主主复制管理器）是一套灵活的脚本程序?用来对mysql replication进行监控和故障迁移?并能管理mysql Master-Master复制的配置 。附带的工具套件可以实现多个slaves的read负载均衡。

Lvs+Keepalived+Mysql Replication

Lvs+keepalived作为目前比较流行的高可用解决方案，lvs提供负载均衡，keepalived作为故障转移，提高系统的可用性。但是一般的mysql高可用为了实现mysql数据的一致性，一般都是采用单点写入。

Lvs+Keepalived+Mysql MM Replication

主主架构同一时刻也只能有一台Master提供写，另一台可以提供读。但是Failover比较简单，一般都使用这种架构，比如淘宝网易。

HearBeat/corosync+Mysql MM Replication

HA-SAN

高可用软件加共享存储SAN做MySQL高可用可以说是简单粗暴，不用复制数据也就不用担心数据不一致性。性能不会受影响，架构配置简单，就是需要Money。

共享存储的方式相比复制的方式弱点就是无预热数据，从一个节点转到另一个节点时所有数据都需要重新载入到内存中。

SAN如果出现问题只能找厂商解决。

HA-DRBD

高可用软件加DRBD其实在架构上跟SAN是相同的，唯一不同的是没有使用SAN网络存储，而是使用Local Disk实时复制磁盘数据，虽然没有MySQL Replication那样主从有数据不一致性，但是DRBD实时复制数据在性能上有很大的影响，网上有人测过大概是降40%性能。

DRBD同样也是无法做数据预热的，也是需要重新载入数据到内存中。

MySQL NDB Cluster

MySQL Cluster环境主要由以下三部分组成：

SQL服务器节点：主要负责实现数据库在存储层之上的所有事情，比如连接管理，查询优化和响应，缓存管理等。

NDB数据节点：主要是实现底层数据存储功能，来保存Cluster的数据，每一个NDB节点保存完整数据的一个分片。

管理节点：负责整个Cluster集群中各个节点的管理工作，包括集群的配置，启动关闭各节点，对各个节点进行常规维护，以及实施数据的备份恢复等工作。

NDB集群需要使用NDB存储引擎，不需要依赖第三方组件，全部都使用官方组件，能保证数据的一致性。如果某个数据节点挂掉，其他数据节点依然可以提供服务。并且数据都是存在内存中的。但管理节点需要做冗余以防挂掉。也有缺点，就是成本高、配置管理都非常复杂，而且某些SQL语句例如join语句需要避免。国内好像使用NDB集群的公司非常少，貌似有些银行有用。

优点：可用性高，高吞吐量和低延迟；每一份数据至少在不同主机上面存在一份拷贝，且冗余数据拷贝实时同步。灵活的分布式体系结构，没有单点故障。可扩展性强，支持在线扩容。

缺点：存在很多限制，比如不支持外键；备份和恢复不方便；重启的时候数据节点将数据load到内存中需要很长时间；连接查询比较消耗资源（MySQL Cluster7.3版本中，增加了适应性join查询，减小了以往join查询对资源的消耗）。

PS：淘宝的TDDL其实就是类似于MySQL NDB cluter这样的一个实现方案。

Tungsten Replicator

Tungsten其实不是MySQL内置的这样一个高可用工具，是第三方提供的一个java写的一个脚本用来检查MySQL二进制，然后传送到Slave上，比较类似于Mysql Replication。但Tungsten是自己写的一套复制方案，用的不多。但Tungsten不但支持MYSQL数据库复制也支持异构数据库的复制，而且对异构数据库复制支持较好，例如MYSQL复制到ORACLE就可以用到。

MariaDB Galera

每种方案都有不同的缺点和优点，配置和应用场景也各有不同，有些偏向于成本低的，有些偏向于数据的可靠性的，有些偏向于数据库的可用性的。所以DBA要结合自己公司的业务情况进行选择适合自己业务情况的高可用方案。