高可用性就是保证尽量少的宕机时间。
尽量少的数据损坏。
一般会受到如下因素影响：
- 环境因素， 比如磁盘耗尽
- 性能问题， 可能是运行了超级慢的sql
- 糟糕的schema和索引设计
- 复制导致数据不一致。
提升平均失效时间 (MTBF)
就是连续运行的时间。 我们可以通过如下的注意点尽量避免：
- 测试回复工具和流程
- 最小权限
- 用好的命名和组织约定避免混乱，比如测试开发库分离
- 升级服务器前使用Percona Tookit检查系统
- 确认服务器配置项
- 通过skip_name_resolve禁止DNS
- 除非证明有效，否则不使用查询缓存。
- 避免使用复杂的特性,如触发器等
- 监控重要组件
- 尽量记录服务器状态和性能做成曲线查看走向
- 定期检查复制完整性
- 备库设置为只读，不要让复制自动启动
- 对查询语句做检查
- 归档并清理不需要的数据
- 为文件系统保留空余空间，在linux中可以使用-m选项为系统本身保留空间。或者创建很大的空文件，在快满是删除
- 养成习惯，评估和管理系统的改变，状态以及性能信息。
降低平均恢复时间（MTTR）
通过建立冗余来避免系统完全失效，比如避免单点。
能够提供冗余和故障转移能力的系统架构
熟悉业务的员工和详细的文档和流程
宕机事后反思
避免单点失效
单个磁盘，单台服务器，单台交换机路由器，单电力网。 任何不冗余的部分都可能是一个失败的单点。
用池加负载均衡，可以动态的切换及避免冗余
共享存储或者复制，做到数据的冗余。
共享存储就是在华为的时候的存储产品，比如NAS。
同步复制
mysql 普通的复制，主服务器挂掉之后会丢数据，使用同步复制保证至少在一条备机持久化之后才能持久化本地，所以减少了丢失。
通常可用的工具：
Mysql Cluster . 可以在任何节点上写入。这些节点拥有等同的读写能力，美羊羊都是冗余数据。
Percona XtraDB Cluster，可以基于已有的存储引擎增加同步复制和集群的特性。其有很多有死的特性：
- 跨界点复制比没有集群快，因为网络写RAM比本地写磁盘块，可以通过降低单节点持久性获得更好的性能。
- 行级并发。可以更好的利用多核CPU
故障转移和恢复
冗余只是一个基础，真正影响可用性的是如何利用这些冗余做转移和恢复。
转移是A出问题了切到B上，等A好了再切回去，这要比仅仅恢复A要好。
通常有如下的手段来做：
- 提升备库。
- 使用虚拟IP，如果服务器出问题，则让虚拟ip指向备库。但是这样可能会因为网络缓存，ip接管等引起错误
- 中间件 可以使用代理，端口转发，LVS等等方法来作为中间件，屏蔽应用和数据库。比如最简单的http代理
总结：
- 两方面考虑增加可用性。 增加两次故障之间的运行时间MTBF，减少从故障恢复的时间。MTTR
- MTBF要减少出错，尽量减少宕机
- MTTR要尽早发现，可以使用监控。
- MTTR还可以使用冗余，并提供故障注意能力。但是遮阳系统更复杂，变成了分布式的。 意味着协调、同步、CAP(一致可用容错只能满足两个)、拜占庭将军问题等
- 如果需要很强的可用性保证不宕机，那么需要Mysql Cluster这样的集群产品。 如果可以容忍故障转移慢一点，标准mYSQL复制也可以
- 如果不是很在意故障转移时间，可以使用NAS等存储层的技术。
