mysql高可用

高可用

一. 定义

服务正常无宕机
服务正常，且无数据丢失

二. 评价

一年内服务不可用时间百分比，9规则
99.9% --- 8h
99.999% --- 5min

三. 导致宕机的原因

35% 运行环境

系统和资源集合，如OS、硬盘、网络

最普遍--磁盘空间耗尽

35% 性能问题

如运行糟糕的SQL，
糟糕的Schema、索引设计
或服务器Bug、错误

20% 复制

主备数据不一致

10% 数据丢失、损坏

drop table 误操作

四. 如何实现高可用性

1. 提升平均失效时间

遵从最小权限
使用InnoDB引擎
除非证明有效，否则禁用查询缓存
监控磁盘空间和RAID卷等关键组件
为文件系统预留空间

2. 降低平均恢复时间

系统建立冗余
避免单点失效

五. 如何避免单点失效？

共享存储SAN，基于磁盘复制DRBD（distributed replicated block device)
mysql同步复制--Cluster方案
基于复制的冗余--MMH方案

六.SAN共享存储方案

SAN(Storage Area Network)网络中不同服务器的数据共享。
服务器正常挂载文件系统并操作，如服务器挂了，备用服务器挂载相同文件系统，执行恢复，然后启动MySQL。共享存储的架构如下:

优点:

1. 可以避免存储外的其它组件引起的数据丢失。
2. 部署简单，切换逻辑简单，对应用透明。
3. 保证主备数据的强一致。

缺点:

1. 共享存储是单点，若共享存储挂了，则会丢失数据。
2. 价格比价昂贵。

七.DRBD磁盘复制方案

DRBD(Distributed Replicated Block Device)
通过网卡将主服务器每个块复制到另一个服务器块设备上，并在主设备提交块之前记录下来

优点

1. 切换对应用透明
2. 保证主备数据的强一致。

缺点：

1. 影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
2. 一般配置两节点同步，可扩展性比较差
3. 备库不能提供读服务，资源浪费

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

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

8.1 keepalived、heartbeat

一种HA软件。
检测服务器(web服务器，DB服务器等)状态，
检查原理是模拟网络请求检测，
检测方式包括主要就是IP,端口(TCP_CHECK)，keepalived也支持自定义脚本。
keepalived通过监听来确认服务器的状态，如果发现服务器故障，则将故障服务器从系统中剔除。

优点

1. 安装配置简单
2. Master故障时，Slave快速切换提供服务，并且对应用透明。

缺点

1. 主备IP在同一个网段
2. 检测机制较弱，需自定义脚本确定Master是否能提供服务，比如更新心跳表等。
3. 无法保证数据一致性，原生的MySQL采用异步复制，
   若Master故障，Slave数据不是最新
4. keepalived软件自身的HA无法保证。

8.2 MHA(Master High Availability)

从宕机的主服务器上保存二进制日志来进行回补。

由两部分组成：
MHA Manager（管理节点）和MHA Node（数据节点）。
MHA Manager定时探测集群中master节点，master故障时，自动将最新数据的slave提升为新master，然后将所有其他的slave重新指向新的master
MHA Node运行在每台MySQL服务器上，主要作用是切换时处理二进制日志

8.3 zookeeper

8.4 Cluster(多点写)方案

8.5 中间件proxy的方案

@参考