高可用性

高可用性意味着更少的宕机时间，通常以百分比表示，本身也是一种暗示，高可用性不是绝对的，只有相对更高的可用性，可用性的9规则是表示可用性最普遍的方法，5个9表示99.999%的正常可用时间，换句话说，每年只允许5分钟的宕机时间。

导致宕机的原因

首先对宕机事件按表现方式而非导致的原因进行分类，一般来说，“运行环境”是排名第一的宕机类别，大约35%的事件属于这一类，运行环境可以看作是支持数据库服务器运行的系统和资源集合，包括操作系统，硬盘以及网络等。性能问题紧随其后，也是占约35%，然后是复制，占20%，最后剩下的10%包括各种类型的数据丢失或损坏，以及其他问题。

下面是一些需要注意的地方

  • 在运行环境的问题中，最普遍的问题是磁盘空间耗尽
  • 在性能问题中，最普遍的宕机原因是运行很糟糕的SQL,也有问题是服务器bug或错误的行为导致的。
  • 糟糕的schema和索引设计是第二大影响性能的问题
  • 复制问题通常由于主备数据不一致导致
  • 数据丢失问题通常由于DROP TABLE 的误操作导致，并总是伴随着缺少可用备份的问题。

复制虽然常被人用来改善可用时间，但却也可能导致宕机，主要由于不正确的使用导致的，也就是说，许多高可用策略可能会产生反作用。

如何实现高可用性

可以通过同时进行以下两步来获得高可用性，

首先，可以尝试避免导致宕机的原因来减少宕机时间，例如通过适当的配置，监控，以及规范或安全保障措施来避免人为错误，第二，尽量保证在发生宕机时能够快速恢复，最常见的策略是在系统中制造冗余，并且具备故障转移能力，这两个维度的高可用性可以通过两个相关的度量来确定，即平均失效时间MTBF和平均恢复时间MTTR.

其次，通过冗余快速恢复。

提升平均失效时间MTBF

对系统变更管理的缺失是所有导致宕机的事件中最普遍的原因，典型错误包括了粗心的升级导致升级失败并遭遇一些bug,或是尚未测试就将schema或查询语句的更改直接运行到线上。或是没有为一些失败的情况制定计划，另外一个导致问题的主要原因是缺少严格的监控，例如因为疏忽没有确认备份是否是可以恢复的。最后，可能是没有正确的监控MYSQL的相关信息。

降低平均恢复时间

在降低恢复时间上进行投资非常重要，一个能够提供冗余和故障转移能力的系统架构，则是降低恢复时间的关键环节，但实现高可用不单单是一个技术问题，还有许多个人和组织的因素，组织和个人在避免宕机和从宕机事件中恢复的成熟度和能力层次各不相同。

团队成员是最重要的高可用资产，所以恢复制定一个好的流程非常重要，拥有熟练技能，应变能力，训练有素的雇员，以及处理应急事件的详细文档和经过仔细测试的流程，对从宕机恢复中有巨大的作用，但是也不能完全依赖工具和系统，因为他们并不能理解实际情况的细微差别。

避免单点失效

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

可以通过两种方法来为系统增加冗余：增加空余容量和重复组件。增加容量余量通常很简单，一个提升可用性的方法是创建一个集群或者服务器池，并使用负载均衡解决方案，如果一台服务器失效，其他服务器可以接管它的负载。

共享存储或磁盘复制

共享存储能够为数据库服务器和存储解耦合，通常使用SAN，使用共享存储时，服务器能够正常挂载文件系统并进行操作。如果服务器挂了，备用服务器可以挂载相同的文件系统，执行需要的恢复操作，并在失效服务器的数据上启动MYSQL,这个过程在逻辑上跟修复那台故障的服务器没什么区别。

共享存储有两个优点，可以避免除存储外的其他任何组件失效所引起的数据丢失，并为非存储组件建立冗余提供可能。

说到底，共享存储和磁盘复制与其说是高可用性的解决方案，不如说是一种保证数据安全的方案，只要拥有数据，就可以从故障中恢复。

MYSQL 同步复制

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

基于复制的冗余

复制管理器是使用标准MYsql复制来创建冗余的工具。尽管可以通过复制来改善可用性，但也有一些“天花板”，会阻止MYSQL当前版本的异步复制和半同步复制获得和真正的同步复制相同的结果，复制无法保证实时的故障转移和数据零丢失，也无法将所有节点等同对待。

故障转移和故障恢复

冗余是很好的技术，但是实际上只有在遇到故障需要恢复时才会用到，冗余不会增加可用性或减少宕机，在故障转移的过程中，高可用性是建立在冗余的基础上，当有一个组件失效，但存在冗余时，可以停止使用发生故障的组件，而使用冗余备件，冗余和故障转移结合可以帮助更快的恢复。 故障转移是一个双向过程，当服务器A失效，服务器B替代它，在修复A后可以再替换回来。

故障转移比仅仅故障中恢复更好，当发生故障时可以根据计划进行故障转移来减少宕机时间。

需要确定故障转移到底有多快，也要知道在一次故障转移后替换一个失效组件应该多快，在你恢复系统耗尽的备件容量之前，会出现冗余不足，并面临额外风险。所以一个完全的故障转移解决方案至少能够监控并自动替换组件。

故障转移最重要的是故障恢复，如果服务器间不能自如切换，故障转移就是一个死胡同，只能是延缓宕机时间而已。下面是一些较普遍的故障转移技术。

提升备库或者切换角色

提升一台备库为主库，或者在一个主主复制结构中调换主动和被动角色。

虚拟IP地址或IP接管

可以为需要提供特定服务的MYSQL实例指定一个逻辑IP地址，当MYSQL实例失效时，可以将IP地址转移到另一台MYSQL服务器上。

中间件解决方案

可以使用代理，端口转发，网络地址转换NAT，或者硬件负载均衡来实现故障转移和故障恢复，这些都是很好的解决方案。 它们是控制应用和服务器间连接的中枢，但是，它们自身也引入了单点失效，需要准备冗余来避免这个问题。

在应用中处理故障转移

有时，让应用来处理故障转移会更简单或者更灵活，例如，如果应用遇到一个错误，这个错误外部观察者正常情况下是无法察觉的，例如关于数据库损坏的错误日志信息，应用可以自己来处理故障转移过程。

但是这种方法十分复杂，也十分笨拙。