MySQL高可用方案

MySQL高可用方案

高可用架构对于互联网服务基本是标配，无论是应用服务还是数据库服务都需要做到高可用。虽然互联网服务号称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无法保证。

更多详情见请继续阅读下一页的精彩内容：