Mysql高可用，实现方案

https://www.cnblogs.com/nuanxin/p/5665840.html

 

对于一个系统而言，可能包含很多模块，比如前端应用，缓存，数据库，搜索，消息队列等，每个模块都需要做到高可用，才能保证整个系统的高可用。

对于数 据库服务而言，高可用可能更复杂，对用户的服务可用，不仅仅是能访问，还需要有正确性保证，因此讨论数据库的高可用方案时，一般会同时考虑方案中数据一致 性问题。

 

1.基于共享存储的方案SAN

优点:
1.可以避免存储外的其它组件引起的数据丢失。
2.部署简单，切换逻辑简单，对应用透明。
3.保证主备数据的强一致。
限制或缺点:
1.共享存储是单点，若共享存储挂了，则会丢失数据。
2.价格比价昂贵。

 

2.基于磁盘复制的方案 DRBD

DRBD(Distributed Replicated Block Device)是一种磁盘复制技术，可以获得和SAN类似的效果。DBRD是一个以linux内核模块方式实现的块级别同步复制技术。它通过网卡将主服务器的每个块复制到另外一个服务器块设备上，并在主设备提交块之前记录下来。

优点：
1.切换对应用透明
2.保证主备数据的强一致。
限制或缺点：
1.影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
2.一般配置两节点同步，可扩展性比较差
3.备库不能提供读服务，资源浪费

 

3.基于主从复制(单点写)方案

实际生产环境中，高可用 更多的是依赖MySQL本身的复制，通过复制为Master制作一个或多个热副本，在Master故障时，将服务切换到热副本。

3.1.keepalived/heartbeat

keepalived是一个HA软件，它的作用是检测服务器(web服务器，DB服务器等)状态，检查原理是模拟网络请求检测，检测方式包括 HTTP_GET|SSL_GET|TCP_CHECK|SMTP_CHECK|MISC_CHECK等。当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)通过从宕机的主服务器上保 存二进制日志来进行回补，能在最大程度上减少数据丢失。

MHA由两部分组成：MHA Manager（管理节点）和MHA Node（数据节点）。MHA可以单独部署在一台独立的机器上管理多个master-slave集群，MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志，确保切换尽量少丢数据。MHA Manager会定时探测集群中的master节点，当master出现故障时，它可以自动将最新数据的slave提升为新的master，然后将所有其 他的slave重新指向新的master，整个故障转移过程对应用程序完全透明。

 

优点：
1. 故障切换时，可以修复多个Slave之间的差异日志，最终使所有Slave保持数据一致，然后从中选择一个充当新的Master，并将其它Slave指向它。
缺点：
1.无法保证强一致，因为从故障Master上保存二进制日志并不总是可行，比如Master磁盘坏了，或者SSH认证失败等。
2.只支持一主多从架构，要求一个复制集群中必须最少有三台数据库服务器，一主二从，即一台充当master，一台充当备用master，另外一台充当从库。
3.MHA管理节点本身的HA无法保证。

 

 3.3.基于zookeeper的高可用

解决HA软件自身高可用的问题，可以为HA软件引入类似Paxos，Raft这样的分布式一致性协议，保证HA软件的可用性。zooKeeper是一个典型的发布/订阅模式的 分布式数据管理与协调框架，通过zookeeper中丰富的数据节点类型进行交叉使用，配合watcher事件通知机制，可以方便地构建一系列分布式应用 涉及的核心功能，比如：数据发布/订阅，负载均衡，分布式协调/通知，集群管理，Master选举，分布式锁和分布式队列等。

 每个MySQL节点上面部署了一个HA client，用于实时向zookeeper汇报本地节点的心跳状态，比如主库crash，通过修改zookeeper(以下简称zk)上的节点信息，来 通知HA。HA节点在zk上注册监听事件，当zk节点发生变化时会自动让HA感知，HA节点可以部署一个或多个，主要用于容灾。HA节点之间通过 zookeeper服务来实现数据的一致性，通过分布式锁保证多个HA节点不会同时对一个主从节点进行切换。HA本身是无状态的，所有MySQL节点状态 信息全部保存在zookeeper服务器上，切换时，HA会对MySQL节点进行复检，然后切换。

 

4.基于Cluster(多点写)方案

上面的方案是伪分布式。下面讨论的两种方案算是真正分布式，同一个数据理论上可以在多个节点写 入

优点：
1.准同步复制
2.多个可同时读写节点，可实现写扩展，较分片方案更进一步
3.数据严格一致
4.服务高可用
缺点：
1.只支持innodb引擎
2.所有表都要有主键
3.由于写要同步到其它节点，存在写扩大问题
4.非常依赖于网络稳定性，不适用于远距离同步

 

5.基于中间件proxy的方案

优点：
1.切换对应用透明
2.可扩展性强，方便分片扩展
3.可以跨机房部署切换

缺点：
1.是一个比较新的组件，没有很多实际应用场景
2.没有解决强一致问题，主备强一致性依赖于MySQL自身(半同步)，以及回滚回补机制。