高可用
一. 定义
服务正常无宕机
服务正常，且无数据丢失二. 评价
一年内服务不可用时间百分比，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。共享存储的架构如下:
优点:
- 可以避免存储外的其它组件引起的数据丢失。
- 部署简单，切换逻辑简单，对应用透明。
保证主备数据的强一致。
缺点:
- 共享存储是单点，若共享存储挂了，则会丢失数据。
价格比价昂贵。
七.DRBD磁盘复制方案
DRBD(Distributed Replicated Block Device)
通过网卡将主服务器每个块复制到另一个服务器块设备上，并在主设备提交块之前记录下来
优点
- 切换对应用透明
- 保证主备数据的强一致。
缺点：
- 影响写入性能，由于每次写磁盘，实质都需要同步到网络服务器。
- 一般配置两节点同步，可扩展性比较差
- 备库不能提供读服务，资源浪费
八. 基于主从复制(单点写)方案
实际中更多是依赖MySQL本身的复制，通过复制为Master制作一个或多个热副本，在Master故障时，将服务切换到热副本
8.1 keepalived、heartbeat
一种HA软件。
检测服务器(web服务器，DB服务器等)状态， 检查原理是模拟网络请求检测， 检测方式包括主要就是IP,端口(TCP_CHECK)，keepalived也支持自定义脚本。 keepalived通过监听来确认服务器的状态，如果发现服务器故障，则将故障服务器从系统中剔除。
优点
- 安装配置简单
- Master故障时，Slave快速切换提供服务，并且对应用透明。
缺点
- 主备IP在同一个网段
- 检测机制较弱，需自定义脚本确定Master是否能提供服务，比如更新心跳表等。
- 无法保证数据一致性，原生的MySQL采用异步复制， 若Master故障，Slave数据不是最新
- 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的方案
@