12、高可用性

什么是高可用性

高可用性不是绝对的，只有相对更高的可用性。百分之百的可用性是不可能达到的。可用性的定义不仅仅包括服务正在运行的时间段，还包括应用是否能以足够好的性能处理请求。

导致宕机的原因

1. 在运行环境的问题中，最普通的问题是磁盘空间耗尽
2. 在性能问题中，最普遍的宕机原因是运行糟糕的SQL
3. 糟糕的schema和索引设计是第二大影响性能的问题
4. 复制问题通常是由于主备数据不一致
5. 数据丢失问题通常是由于 DROP TABLE 的误操作导致，并总是伴随着缺少可用备份的问题

如何实现高可用性

首先可以尝试避免导致宕机的原因来减少宕机时间。其次尽量保证在发生宕机时能够快速恢复。最常见的策略就是在系统中制造冗余，具备故障转移能力。

提升平均失效时间

其实只要尽职尽责地做好一些应做的事情，就可以避免很多宕机的情况。大部分的宕机事件都是可以通过全面的常识性系统管理办法来避免。例如：

1. 测试恢复工具和流程，包括从备份中恢复数据
2. 遵从最小权限原则
3. 保持系统干净、整洁等等

降低平均恢复时间

一个能够提供冗余和故障转移的系统架构，则是降低恢复时间的关键环节。

避免单点失效

找到并消除系统中的可能失效的单点，并结合切换到备用组件的机制，这是一种通过减少恢复时间来改善可用性的方法。

共享存储或磁盘复制

共享存储有两个优点：可以避免除存储外的其他任何组件失效所引起的数据丢失，并为非存储组件建立冗余提供可能。因此他有助于减少系统一些部分的可用性需求，这样就可以集中精力关注一小部分组件来获得高可用性。不过共享存储本身也是有可能失效的，如果共享存储失效了，那整个系统也失效了。
共享存储本身也有风险，如果Mysql崩溃等故障导致数据文件损坏，可能会导致备用服务器无法恢复。所以建议使用共享存储策略时选择InnoDB存储引擎或其他稳定的ACID存储引擎。
Mysql中最普遍使用的磁盘复制技术是DRBD。主要有以下几个缺点：

  1. DRBD的故障转移无法做好秒级以内。
  2. 成本很昂贵，必须在主动-被动模式下运行。
  3. 对于MyISAM表实际上用处不大，因为MyISAM表崩溃后需要花费很长时间来检查和修复。
  4. DRBD无法替代备份。
  5. 对写操作而言增加了负担。

Mysql同步复制

当使用同步复制时，主库上的事务只有在至少一个备库上提交后才能认为其执行完成。这实现了两个目标：当服务器崩溃时没有提交的事务会丢失，并且至少有一个备库拥有实时的数据副本。大多数同步复制架构运行在主动-主动模式，这意味着每个服务器在任何时候都是故障转移的候选者。这使得通过冗余获得高可用性更加容易。

基于复制的冗余

复制管理器是使用标准Mysql复制来创建冗余的工具。尽管可以通过复制来改善可用性，但也有有一些限制会阻止Mysql当前版本的异步复制和半同步复制获得和真正的同步复制相同的结果。

故障转移和故障恢复

冗余是很好的技术，但实际上只有在遇到故障需要恢复的时候才会用到。冗余一点也不会增加可用性或减少宕机。在故障转移中，高可用性是建立在冗余的基础上。当有一个组件失效，但存在冗余时，可以停止使用发生故障的组件，而使用冗余备件。
故障转移比仅仅从故障中恢复更好。也可以针对一些情况制定故障转移计划，例如升级、schema变更、应用修改或者定期维护，当发生故障时可以根据计划进行故障转移来减少宕机时间。
故障转移最重要的部分就是故障恢复。如果服务器间不能切换自如，故障转移就是一个死胡同，只能是延缓宕机时间而已。