共计 9415 个字符，预计需要花费 24 分钟才能阅读完成。
高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。虽然互联网服务号称 7 *24 小时不间断服务，但多多少少有一些时候服务不可用，比如某些时候网页打不开，百度不能搜索或者无法发微博，发微信等。一般而言，衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考，要做到 3 个 9 的可用性，一年内只能累计有 8 个小时不可服务，而如果要做到 5 个 9 的可用性，则一年内只能累计 5 分钟服务中断。所以虽说每个公司都说自己的服务是 7 *24 不间断的，但实际上能做到 5 个 9 的屈指可数，甚至根本做不到，国内互联网巨头 BAT(百度，阿里巴巴，腾讯)都有因为故障导致的停服问题。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，一般会同时考虑方案中数据一致性问题。今天这篇文章主要讨论 MySQL 数据库的高可用方案，介绍每种方案的特性以及优缺点，本文是对各种方案的总结，希望抛砖引玉，和大家一起讨论。
1. 基于共享存储的方案 SAN
方案介绍：SAN(Storage Area Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动 MySQL。共享存储的架构如下:
优点:
1. 可以避免存储外的其它组件引起的数据丢失。
2. 部署简单，切换逻辑简单，对应用透明。
3. 保证主备数据的强一致。
限制或缺点:
1. 共享存储是单点，若共享存储挂了，则会丢失数据。
2. 价格比价昂贵。
2. 基于磁盘复制的方案 DRBD
方案介绍：DRBD(Distributed Replicated Block Device)是一种磁盘复制技术，可以获得和 SAN 类似的效果。DBRD 是一个以 linux 内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD 与 SAN 类似，也是有一个热备机器，开始提供服务时会使用和故障机器相同的数据，只不过 DRBD 的数据是复制存储，不是共享存储。DRBD 的架构图如下：
优点：
1. 切换对应用透明
2. 保证主备数据的强一致。
限制或缺点：
1. 影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
2. 一般配置两节点同步，可扩展性比较差
3. 备库不能提供读服务，资源浪费
3. 基于主从复制 (单点写) 方案
前面讨论的两种方案分别依赖于底层的共享存储和磁盘复制技术，来解决 MYSQL 服务器单点和磁盘单点的问题。而实际生产环境中，高可用更多的是依赖 MySQL 本身的复制，通过复制为 Master 制作一个或多个热副本，在 Master 故障时，将服务切换到热副本。下面的几种方案都是基于主从复制的方案，方案由简单到复杂，功能也越来越强大，实施难度由易到难，各位可以根据实际情况选择合适的方案。
3.1.keepalived/heartbeat
方案介绍：
keepalived 是一个 HA 软件，它的作用是检测服务器 (web 服务器，DB 服务器等) 状态，检查原理是模拟网络请求检测，检测方式包括 HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK 等。对于 DB 服务器而言，主要就是 IP, 端口(TCP_CHECK)，但这可能不够(比如 DB 服务器 ReadOnly)，因此 keepalived 也支持自定义脚本。keepalived 通过监听来确认服务器的状态，如果发现服务器故障，则将故障服务器从系统中剔除。keepalived 的高可用架构如下图，分别在主、从服务器上安装 keepalived 的软件，并配置同样的 VIP，VIP 层将真实 IP 屏蔽，应用服务器通过访问 VIP 来获取 DB 服务。当 Master 故障时，keepalived 感知，并将 Slave 提升主，继续提供服务对应用层透明。
优点：
1. 安装配置简单
2. Master 故障时，Slave 快速切换提供服务，并且对应用透明。
限制或缺点：
1. 需要主备的 IP 在同一个网段。
2. 提供的检测机制比较弱，需要自定义脚本来确定 Master 是否能提供服务，比如更新心跳表等。
3. 无法保证数据的一致性，原生的 MySQL 采用异步复制，若 Master 故障，Slave 数据可能不是最新，导致数据丢失，因此切换时要考虑 Slave 延迟的因素，确定切换策略。对于强一致需求的场景，可以开启 (semi-sync) 半同步，来减少数据丢失。
4.keepalived 软件自身的 HA 无法保证。
3.2.MHA
方案介绍：MHA(Master High Availability)是一位日本 MySQL 大牛用 Perl 写的一套 MySQL 故障切换方案，来保证数据库的高可用，MHA 通过从宕机的主服务器上保存二进制日志来进行回补，能在最大程度上减少数据丢失。MHA 由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。MHA 可以单独部署在一台独立的机器上管理多个 master-slave 集群，MHA Node 运行在每台 MySQL 服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master，整个故障转移过程对应用程序完全透明。MHA 的架构如下：
MHA failover 过程：
a. 检测到 Master 异常，进行一系列判断，最后确定 Master 宕掉；
b. 检查配置信息，罗列出当前架构中各节点的状态；
c. 根据定义的脚本处理故障的 Master，VIP 漂移或者关掉 mysqld 服务；
d. 所有 Slave 比较位点，选出位点最新的 Slave，再与 Master 比较并获得 binlog 的差异，copy 到管理节点；
e. 从候选节点中选择新的 Master，新的 Master 会和位点最新的 Slave 进行比较并获得 relaylog 的差异；
f. 管理节点把 binlog 的差异 copy 到新 Master，新 Master 应用 binlog 差异和 relaylog 差异，最后获得位点信息，并接受写请求(read_only=0)；
g. 其他 Slave 与位点最新的 Slave 进行比较，并获得 relaylog 的差异，copy 到对应的 Slave；
h. 管理节点把 binlog 的差异 copy 到每个 Slave，比较 Exec_Master_Log_Pos 和 Read_Master_Log_Pos，获得差异日志；
i. 每个 Slave 应用所有差异日志，然后 reset slave 并重新指向新 Master；
j. 新 Master reset slave 来清除 Slave 信息。
优点：
1. 代码开源，方便结合业务场景二次开发
2. 故障切换时，可以修复多个 Slave 之间的差异日志，最终使所有 Slave 保持数据一致，然后从中选择一个充当新的 Master，并将其它 Slave 指向它。
3. 可以灵活选择 VIP 方案或者全局目录数据库方案(更改 Master IP 映射) 来进行切换。
缺点：
1. 无法保证强一致，因为从故障 Master 上保存二进制日志并不总是可行，比如 Master 磁盘坏了，或者 SSH 认证失败等。
2. 只支持一主多从架构，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当 master，一台充当备用 master，另外一台充当从库。
3. 采用全局目录数据库方案切换时，需要应用感知变化，因此对应用不透明，因此要保持切换对应用透明，依然依赖于 VIP。
4. 不适用于大规模集群部署，配置比较复杂。
5.MHA 管理节点本身的 HA 无法保证。
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2016-05/130890p2.htm
3.3. 基于 zookeeper 的高可用
方案介绍：
从前面的讨论可以看到，无论是 keepalived 方案还是 MHA 方案，都无法解决 HA 软件自身的高可用问题，因为 HA 本身是单点。那么如果将 HA 也引入多个副本呢？那么又带来新的问题，1.HA 软件之间如何保证强同步。2. 如何确保不会有多个 HA 同时进行切换动作。这两个问题实质都分布式系统一致性问题，为此，可以为 HA 软件引入类似 Paxos，Raft 这样的分布式一致性协议，保证 HA 软件的可用性。zooKeeper 是一个典型的发布 / 订阅模式的分布式数据管理与协调框架，通过 zookeeper 中丰富的数据节点类型进行交叉使用，配合 watcher 事件通知机制，可以方便地构建一系列分布式应用涉及的核心功能，比如：数据发布 / 订阅，负载均衡，分布式协调 / 通知，集群管理，Master 选举，分布式锁和分布式队列等。zookeeper 是一个很大话题，大家可以 google 去找更多的信息，我这里主要讨论 zookeeper 如何解决 HA 自身可用性问题。架构图如下：
图中每个 MySQL 节点上面部署了一个 HA client，用于实时向 zookeeper 汇报本地节点的心跳状态，比如主库 crash，通过修改 zookeeper(以下简称 zk)上的节点信息，来通知 HA。HA 节点在 zk 上注册监听事件，当 zk 节点发生变化时会自动让 HA 感知，HA 节点可以部署一个或多个，主要用于容灾。HA 节点之间通过 zookeeper 服务来实现数据的一致性，通过分布式锁保证多个 HA 节点不会同时对一个主从节点进行切换。HA 本身是无状态的，所有 MySQL 节点状态信息全部保存在 zookeeper 服务器上，切换时，HA 会对 MySQL 节点进行复检，然后切换。我们看看引入 zookeeper 后的切换流程：
a.HA client 检测到 Master 异常，进行一系列判断，最后确定 Master 宕掉；
b.HA client 删除 Master 在 zk 上的节点信息；
c. 由于监听机制，HA 会感知到有节点被删除；
d.HA 对 MySQL 节点进行复检，比如建立连接，更新心跳表等
e. 确认异常后，则进行切换。
我们再看看这种架构下，是否能保证 HA 自身的高可用
(1). 如果 HA-client 本身挂了，MySQL 节点正常？
HA-Client 管理的 MySQL 节点无法与 zookeeper 保持心跳，zk 服务将节点删除，HA 会感知到这种变化，准备尝试一次切换，切换前，会进行复检，复检时发现 MySQL 节点是 OK 的，则不会切换。
(2).MySQL 节点与 zookeeper 的网络断了，那么表现如何？
由于 HA-Client 与节点在同一台主机，因此 HA-client 无法再定时向 zk 汇报心跳，zk 会将对应的 MySQL 节点信息删除，HA 尝试复检，依然失败，则进行切换。
(3).HA 挂了，表现如何？
由于 HA 无状态，并且有多个副本，因此一个 HA 挂了，不会对整个系统造成影响。
优点：
1. 保证了整个系统的高可用
2. 主从的强一致依赖于 MySQL 本身，比如半同步，或者外围工具的回补策略，类似 MHA。
3. 扩展性非常好，可以管理大规模集群。
缺点：
1. 引入 zk，整个系统变得复杂。
4. 基于 Cluster(多点写)方案
第 3 节讨论的方案基本是目前业内使用的主流方案，这类方案的特点是，单点写。虽然我们可以借助中间件进行分片(sharding)，但是对于同一份数据，依然只允许一个节点写，从这个角度来说，上面的方案是伪分布式。下面讨论的两种方案算是真正分布式，同一个数据理论上可以在多个节点写入，类似于 Oracle 的 RAC，EMC 的 GreenPlum 这种分布式数据库。在 MySQL 领域，主要提供了 2 种解决方案：基于 Galera 的 PXC 和 NDB Cluster。MySQL Cluster 实现基于 NDB 存储引擎，使用很多局限性，而 PXC 是基于 innodb 引擎，虽然也有局限性，但由于目前 innodb 使用非常广泛，所以有一定的参考价值。目前据我所知，去哪儿公司在他们的生产环境中使用了 PXC 方案。PXC(Percona XtraDB Cluster) 的架构图如下：
优点：
1. 准同步复制
2. 多个可同时读写节点，可实现写扩展，较分片方案更进一步
3. 自动节点管理
4. 数据严格一致
5. 服务高可用
缺点：
1. 只支持 innodb 引擎
2. 所有表都要有主键
3. 由于写要同步到其它节点，存在写扩大问题
4. 非常依赖于网络稳定性，不适用于远距离同步
5. 基于中间件 proxy 的方案
准确地来说，中间件与高可用没有特别大的关系，因为切换都是在数据库层完成，但引入中间层后，使得对应用更透明。在引入中间件之前，所有的方案，基本都依赖于 VIP 漂移机制，或者不依赖于 VIP 又不能保证对应用透明。通过加入中间件层，可以同时实现对应用透明和高可用。此外中间层还可以做 sharding，方便写扩展。proxy 的方案很多，比如 mysql 自带的 mysql-proxy 和 fabric，阿里巴巴的 cobar 和 tddl 等。我们以 fabric 为例，其架构图如下:
应用都请求 Fabric 连接器，然后通过使用 XML-RPC 协议访问 Fabric 节点，Fabric 节点依赖于备用存储 (backing store)，里面存储整个 HA 集群的元数据信息。连接器读取 backing store 的信息，然后将元数据缓存到 cache，这样做的好处就是减少每次建立连接时与管理节点交互所带来的开销。Fabric 节点可管理多个 HA Group，每个 HA Group 里有一个 Primary 和多个 Secondary(slave)，当 Primary 异常的时候会从 Secondary 中选出最合适的节点提升为新 Primary，其余 Secondary 都将重新指向新 Primary。这些都是自动操作，对业务是无感知的，HA 切换之后还需要通知连接器更新的元数据信息。
优点：
1. 切换对应用透明
2. 可扩展性强，方便分片扩展
3. 可以跨机房部署切换
缺点：
1. 是一个比较新的组件，没有很多实际应用场景
2. 没有解决强一致问题，主备强一致性依赖于 MySQL 自身(半同步)，以及回滚回补机制。
总结
以上介绍了目前 MySQL 几种典型的高可用架构，包括基于共享存储方案，基于磁盘复制方案和基于主从复制的方案。对于主从复制方案，分别介绍了 keepalived，MHA 以及引入 zookeeper 的方案。对于每种方案，都从持续可用，数据强一致性，以及切换对应用的透明性进行说明。个人觉得基于 MySQL 复制的方案是主流，也非常成熟，引入中间件和引入 zookeeper 虽然能将系统的可用性做地更好，可支撑的规模更大，但也对研发和运维也提出了更高的要求。因此，在选择方案时，要根据业务场景和运维规模做抉择。
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-05/130890.htm
高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。虽然互联网服务号称 7 *24 小时不间断服务，但多多少少有一些时候服务不可用，比如某些时候网页打不开，百度不能搜索或者无法发微博，发微信等。一般而言，衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考，要做到 3 个 9 的可用性，一年内只能累计有 8 个小时不可服务，而如果要做到 5 个 9 的可用性，则一年内只能累计 5 分钟服务中断。所以虽说每个公司都说自己的服务是 7 *24 不间断的，但实际上能做到 5 个 9 的屈指可数，甚至根本做不到，国内互联网巨头 BAT(百度，阿里巴巴，腾讯)都有因为故障导致的停服问题。对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。对于数据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，一般会同时考虑方案中数据一致性问题。今天这篇文章主要讨论 MySQL 数据库的高可用方案，介绍每种方案的特性以及优缺点，本文是对各种方案的总结，希望抛砖引玉，和大家一起讨论。
1. 基于共享存储的方案 SAN
方案介绍：SAN(Storage Area Network)简单点说就是可以实现网络中不同服务器的数据共享，共享存储能够为数据库服务器和存储解耦。使用共享存储时，服务器能够正常挂载文件系统并操作，如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，然后启动 MySQL。共享存储的架构如下:
优点:
1. 可以避免存储外的其它组件引起的数据丢失。
2. 部署简单，切换逻辑简单，对应用透明。
3. 保证主备数据的强一致。
限制或缺点:
1. 共享存储是单点，若共享存储挂了，则会丢失数据。
2. 价格比价昂贵。
2. 基于磁盘复制的方案 DRBD
方案介绍：DRBD(Distributed Replicated Block Device)是一种磁盘复制技术，可以获得和 SAN 类似的效果。DBRD 是一个以 linux 内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。DRBD 与 SAN 类似，也是有一个热备机器，开始提供服务时会使用和故障机器相同的数据，只不过 DRBD 的数据是复制存储，不是共享存储。DRBD 的架构图如下：
优点：
1. 切换对应用透明
2. 保证主备数据的强一致。
限制或缺点：
1. 影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
2. 一般配置两节点同步，可扩展性比较差
3. 备库不能提供读服务，资源浪费
3. 基于主从复制 (单点写) 方案
前面讨论的两种方案分别依赖于底层的共享存储和磁盘复制技术，来解决 MYSQL 服务器单点和磁盘单点的问题。而实际生产环境中，高可用更多的是依赖 MySQL 本身的复制，通过复制为 Master 制作一个或多个热副本，在 Master 故障时，将服务切换到热副本。下面的几种方案都是基于主从复制的方案，方案由简单到复杂，功能也越来越强大，实施难度由易到难，各位可以根据实际情况选择合适的方案。
3.1.keepalived/heartbeat
方案介绍：
keepalived 是一个 HA 软件，它的作用是检测服务器 (web 服务器，DB 服务器等) 状态，检查原理是模拟网络请求检测，检测方式包括 HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK 等。对于 DB 服务器而言，主要就是 IP, 端口(TCP_CHECK)，但这可能不够(比如 DB 服务器 ReadOnly)，因此 keepalived 也支持自定义脚本。keepalived 通过监听来确认服务器的状态，如果发现服务器故障，则将故障服务器从系统中剔除。keepalived 的高可用架构如下图，分别在主、从服务器上安装 keepalived 的软件，并配置同样的 VIP，VIP 层将真实 IP 屏蔽，应用服务器通过访问 VIP 来获取 DB 服务。当 Master 故障时，keepalived 感知，并将 Slave 提升主，继续提供服务对应用层透明。
优点：
1. 安装配置简单
2. Master 故障时，Slave 快速切换提供服务，并且对应用透明。
限制或缺点：
1. 需要主备的 IP 在同一个网段。
2. 提供的检测机制比较弱，需要自定义脚本来确定 Master 是否能提供服务，比如更新心跳表等。
3. 无法保证数据的一致性，原生的 MySQL 采用异步复制，若 Master 故障，Slave 数据可能不是最新，导致数据丢失，因此切换时要考虑 Slave 延迟的因素，确定切换策略。对于强一致需求的场景，可以开启 (semi-sync) 半同步，来减少数据丢失。
4.keepalived 软件自身的 HA 无法保证。
3.2.MHA
方案介绍：MHA(Master High Availability)是一位日本 MySQL 大牛用 Perl 写的一套 MySQL 故障切换方案，来保证数据库的高可用，MHA 通过从宕机的主服务器上保存二进制日志来进行回补，能在最大程度上减少数据丢失。MHA 由两部分组成：MHA Manager（管理节点）和 MHA Node（数据节点）。MHA 可以单独部署在一台独立的机器上管理多个 master-slave 集群，MHA Node 运行在每台 MySQL 服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。MHA Manager 会定时探测集群中的 master 节点，当 master 出现故障时，它可以自动将最新数据的 slave 提升为新的 master，然后将所有其他的 slave 重新指向新的 master，整个故障转移过程对应用程序完全透明。MHA 的架构如下：
MHA failover 过程：
a. 检测到 Master 异常，进行一系列判断，最后确定 Master 宕掉；
b. 检查配置信息，罗列出当前架构中各节点的状态；
c. 根据定义的脚本处理故障的 Master，VIP 漂移或者关掉 mysqld 服务；
d. 所有 Slave 比较位点，选出位点最新的 Slave，再与 Master 比较并获得 binlog 的差异，copy 到管理节点；
e. 从候选节点中选择新的 Master，新的 Master 会和位点最新的 Slave 进行比较并获得 relaylog 的差异；
f. 管理节点把 binlog 的差异 copy 到新 Master，新 Master 应用 binlog 差异和 relaylog 差异，最后获得位点信息，并接受写请求(read_only=0)；
g. 其他 Slave 与位点最新的 Slave 进行比较，并获得 relaylog 的差异，copy 到对应的 Slave；
h. 管理节点把 binlog 的差异 copy 到每个 Slave，比较 Exec_Master_Log_Pos 和 Read_Master_Log_Pos，获得差异日志；
i. 每个 Slave 应用所有差异日志，然后 reset slave 并重新指向新 Master；
j. 新 Master reset slave 来清除 Slave 信息。
优点：
1. 代码开源，方便结合业务场景二次开发
2. 故障切换时，可以修复多个 Slave 之间的差异日志，最终使所有 Slave 保持数据一致，然后从中选择一个充当新的 Master，并将其它 Slave 指向它。
3. 可以灵活选择 VIP 方案或者全局目录数据库方案(更改 Master IP 映射) 来进行切换。
缺点：
1. 无法保证强一致，因为从故障 Master 上保存二进制日志并不总是可行，比如 Master 磁盘坏了，或者 SSH 认证失败等。
2. 只支持一主多从架构，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当 master，一台充当备用 master，另外一台充当从库。
3. 采用全局目录数据库方案切换时，需要应用感知变化，因此对应用不透明，因此要保持切换对应用透明，依然依赖于 VIP。
4. 不适用于大规模集群部署，配置比较复杂。
5.MHA 管理节点本身的 HA 无法保证。
更多详情见请继续阅读下一页的精彩内容：http://www.linuxidc.com/Linux/2016-05/130890p2.htm
