MySQL 提供的高可能解决方案

在选择一个高可用方案时，MySQL 提供了众多的选择。包括 MySQL 复制，MySQL 集群， 免费和开源的解决方案，当然，还有来自我们认证合作伙伴的产品。在本节中，我们将 关注来自 MySQL 的高可用解决方案。

MySQL 复制
MySQL 本身支持单向，异步复制。MySQL 复制以一台服务器为主机，其它一个或多个服

务器为从机。恰恰与 MySQL 集群相反，集群是同步复制。

异步数据复制意味着数据从一个机器拷贝到另一个机器时，存在一定的延迟。通常，这 种延迟是由网络带宽，可用资源，以及管理员预先设定的时间间隔所决定。但是，只要 正确配置和调整，复制在很多应用中可以认为是即时的。同步复制意味着数据可以在同 一时刻向一台或是多台机器提交，通常叫做”双步提交”。

标准 MySQL 复制，主服务器将更新写到二进制日志文件并且维护一个索引文件以保存日 志的更新轨迹。二进制日志里保存的更新记录将会被发送到从机。当从机连接至主机， 他会从日志里读取从最后一次成功更新的位置。然后会执行从那个时间点之后的所有更 新， 完了就一直处于等待状态。

下图 1 是一个基本的 MySQL 主从配置。

图1 主从复制提供以下优势，可用性，性能，易用性。

• 一旦主机故障，应用可以转移到从机。
• 在主机和从机进行负载切分，可以带来更快的响应时间。简单”读”数据的查询， 比如 SELECT，可以用从机处理以减少主机的压力。更新的查询被分到主机处理，以 便结果数据能及时的反馈。这种负载均衡策略在更新比较少的应用中非常有效。(通 常情况是这样的)
• 另一个使用复制的好处是数据库的备份可以使用从机来做，同时也不会影响主机的 资源。在备份进行时，主机继续处理更新。 图 2 论证了以上两点。

图2

虽然 MySQL 主从复制可以解决很多高可用问题。但是有两种情况，需要开发人员/管理 员注意:
第一， 应用必须清楚的知道它所使用的是主从复制架构，所以必须在应用中指明，写

操作发送到主机，而读操作发送到从机。
第二， 制定一个策略，用于在主机出现故障时，怎样进行漂移。另外，也需要考虑怎

样将系统回复到故障前的初始状态。
下图 3 描述了在标准的故障切换下，MySQL 复制的配置。

图3
下图 4 描述了其它类型的复制拓扑图，以及一些建议。

图4 复制拓扑结构中配置多主是有可能的，但是这会带来一些在单主环境中不存在的问题。

特别需要注意的是这样的配置局限性和可能会出现的问题。

使用主从复制时，最需要注意的是主从之间可能会出现的不同步。当你使用复制，所有 的更新应该是在主服务器上。否则，你必须小心以下的情况，在一个机器上更新，在另 一台机器上也更新。为了避免这种情况，开发人员采用的策略叫做”冲突解决”。

MySQL 主从复制本身并不处理冲突解决或是故障切换。为了避免编写额外的代码或是脚 本，可以考虑使用一些高可用方案，这些都会在下文中介绍。

使用 MySQL 主从复制进行灾难恢复

MySQL 复制可以在地理位置上做冗余，以防备可能的灾难。不管你使用标准的 MySQL 服 务器，MySQL 集群或是本文中提到的其它高可用解决方案，MySQL 都可以向你提供复制 环境，以应对灾后恢复工作。当然，这些架构的实施有一定的特殊要求，复制所用的带 宽，通信协议的安全性和应用故障后，预期的切换时间，等等。

MySQL 集群

MySQL 集群设计的初衷是满足世界上对吞吐量和响应时间有严格要求的企业应用。MySQL 集群是一个采用无共享存储的数据存储模式，实时同步且支持快速故障切换，事务和内 存数据存储，而无需特殊网络，硬件或是存储要求。

此种设计的数据库使得 MySQL 集群具有高可用性和可靠性，因为单点故障已不复存在。

集群中的任一个节点的失效都不会影响整个系统。一个应用，比如，事务可以持续的执 行，即便是的数据节点失效的时候。已经证明，MySQL 集群可以每秒处理 10,000 个分布 式事务，并且在各个数据节点间复制。

在 5.1 中，MySQL 集群不仅支持内存存储数据，也支持磁盘上的数据存储。这种安排使 得应用程序可从存储于内存中获益，这不仅增加了应用程序的性能，也通过异步的将事 务日志写到磁盘上，降低了 I/O 瓶颈。但是，随着基于磁盘的存储的引入，那些并不需 要更好性能的更大数据集也可以进入内存当中，也可以从中获益。

MySQL 集群在软件，网络，硬件故障时，提供快速的故障恢复。 MySQL 集群使用同步复 制以将事务信息推送到各个数据节点。使用 MySQL 集群节约了在共享架构上会出现的重 写日志文件的操作。MySQL 集群数据节点在出现故障时，可以自动重启，恢复，动态配 置它们自己，而不需要开发人员编程以在应用中写入此类代码。

MySQL 集群节点可自动恢复，这确保当切换至其它数据节点时，还是能保留一份一致性 的数据。因为所有的数据节点都可能因为硬件故障而失效，MySQL 集群使用检查点和日 志来确保整个系统可以安全的恢复到一个一致性状态。更进一步，MySQL 还可以使用地 理复制确保系统高可用和一致性。

以下是 MySQL 集群的简要描述

• 数据节点用以存储所有属于 MySQL Cluster 的数据。这些数据在数据节点之间被复 制以保证在一个或多个节点出现故障时集群仍然持续可用。数据节点轮流处理事务。 随着数据复制份数的增加整个系统的数据冗余性相应提高。
• 管理节点用以控制系统启动时的初始配置，在集群设置发生改变时又被重新利用。 通常只需配置一个管理节点;然而为了排除单点故障需要，有可能的话，尽量增加 管理节点的数量。管理节点只在集群启动和发生配置变化的时候起作用，集群启动 以后，不论管理节点处于什么状态， 整个集群都将保持其在线和可用状态。
• MySQL 服务节点用于存取已集群数据节点上的数据，给软件开发者提供了一个标准 的 SQL 语言编程接口。MySQL 服务节点负责向数据节点传送访问请求，这使 MySQL 使用者无需知道具体的集群过程，也无需进行数据库操作的底层编程。 下图5 描述了一个MySQL集群架构示例，其为MySQL所有的组件提供了最小限度的冗余。 如中的 6 个节点由如下组成:

• 两个管理节点
• 两个数据节点
• 两个 MySQL 服务节点

现在，我们来看一下 MySQL 集群是怎样将数据分布到数据节点上的。首先，将存储于集 群的数据被切割成数据片。这些数据片根据事先指定的副本数，在可用的数据节点上进

行相应的复制。比如，在图 6 中，我们有四个数据片，将它们分别分布到四个数据节点。 每个碎片都复制两次。结果，集群将它们标记为首要和次要数据片。根据这些数据片创 建数据组。构成一个副本的数据节点组成一个节点组。

图6
在图 7 描述了一个 MySQL 集群，在其节点组 1 和 2 中，我们可以看到数据仍然可用，即

便是有两个数据节点不可用。

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