高可用性就是保证尽量少的宕机时间。
尽量少的数据损坏。
一般会受到如下因素影响：

  • 环境因素， 比如磁盘耗尽
  • 性能问题， 可能是运行了超级慢的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等存储层的技术。