我们之前了解了复制、扩展性，接下来就让我们来了解可用性。归根到底，高可用性就意味着 "更少的宕机时间"。
老规矩，讨论一个名词，首先要给它下个定义，那么什么是可用性？
1 什么是可用性
我们常见的可用性通常以百分比表示，这本身就有其隐藏的意味：高可用性不是绝对的。换句话说，100% 的可用性是不可能达到的。没错，这里可以这么肯定的说。
我们一般用 “9” 的个数来描述可用性。X个9表示在数据中心运行1年时间的使用过程中，各系统可以正常使用时间与总时间（1年）之比。例如：“5 个 9” 表示 99.999%，那么应用宕机时间 t：
(1-99.999%) * 3600 * 24 * 365 = 315.36s = 5.256m
因此，我们可以说，“5 个 9” 表示应用每年只允许 5.256 分钟的宕机时间。同样的计算，我们可以得出 3 个 9 每年宕机时间为 8.76 小时，4 个 9 的是 52.6 分钟。
实际上，5 个 9 对于大多数应用来说已经是很难做到的，但是对于一些大型公司，肯定还会去尝试获得更多的 "9"，已尽量减少应用的宕机时间，降低宕机成本。
每个应用对可用性的需求各不相同。在设定一个目标值之前，一定要考虑清楚是不是确实需要达到这个目标。可用性的效果和开销对应的比例并不是线性增长的，每提高一点可用性，所花费的成本都会远超之前。
因此，对于可用性，我们可以遵循这样一个原则：
能够承担多少宕机成本，就保证相应的可用时间。
说起来可能有点绕，简单来说：对于有 10W 用户的应用，
假设实现 5 个 9 需要 100W，每年应用即使宕机 9 小时，总损失也才 50W，你说这个应用有必要去实现 5 个 9 的可用性吗？
另外，我们上面给可用性定义成了 “宕机时间”，但实际上可用性还应该包括应用是否能以足够好的性能处理请求。对于一个大型服务器而言，重启 MySQL 后，可能需要几个小时才能预热数据以保证请求的响应时间。这里的几个小时也应该包括在宕机时间内。
到此为止，我们应该有个大致的印象，可用性与应用宕机有关系。接下来，让我们再深入一步，了解下应用宕机的原因。
2 导致宕机的原因
我们最常听到的数据库宕机原因可能是** SQL 性能很差**。但实际上并非如此，按表现方式导致宕机的原因分为以下几类：
| 宕机事件表现形式 | 占比 | 导致宕机的原因 |
|---|---|---|
| 运行环境 | 35% | 磁盘空间耗尽 |
| 性能问题 | 35% | 1. 低性能 SQL；2. 服务器 BUG；3. 糟糕的表结构设计和索引设计 |
| 复制 | 20% | 主备数据不一致 |
| 数据丢失或损坏 | 10% | 误操作删除数据，缺少备份 |
运行环境通常可以看作是支持数据库服务器运行的系统资源集合，包括操作系统、硬盘以及网络等。
另外，我们虽然经常用复制来提高可用时间，但它也是导致宕机的重要 “元凶” 之一。这也说明了一个普遍的情况：
许多高可用策略可能会产生反作用
了解了可用性的定义及其降低可用性的因素，我们就要来考虑如何提高系统的可用性了。
3 如何实现高可用性
通过上面的分析，也许你已经发现了，我们可用性取决于两个时间：
- 应用的平均失效时间
- 应用的平均恢复时间
因此，提高可用性也可以从这两个方面入手。首先，可以尽量避免应用宕机来减少宕机时间。实际上，通过适当的配置、监控，以及规范或安全保障措施，很多导致宕机的问题很容易可以避免。
其次，尽量保证在发生宕机时，能够快速恢复。最常见的策略是在系统中制造冗余，并且保证系统的故障转移能力。
接下来，让我们一起来了解具体针对性措施。
3.1 降低平均失效时间
我们对系统变更缺少管理是所有导致宕机事件中最普遍的原因。典型的错误包括粗心的升级导致升级失败并碰到一些 bug，或是尚未测试就将数据表结构或查询语句的更改直接在线上运行，或者是没有为一些失败的情况制定对应计划，例如达到了磁盘容量限制等。
另外一个导致宕机的主要原因是缺少严格的评估。例如因为疏忽没有确认备份是否是可恢复的。
还有就是可能没有准确的监控 MySQL 的相关信息。例如缓存命中率报警可能只是误报，并不能说明出现问题，致使我们认为监控系统没有用，就忽略了真正出现问题的报警。导致 boss 问你，为什么磁盘满了没有收到报警信息时，你一脸无辜的看着他。
因此，只要我们多做些针对性的工作，就可以避免很多宕机时间。具体可以从以下措施着手：
- 测试恢复工具和流程，包括从备份中恢复数据。
- 遵从最小权限原则。
- 保持系统干净、整洁。
- 使用好的命名和组织约定来避免产生混乱。例如服务器是用于开发还是生产环境。
- 谨慎安排升级数据库服务器。
- 在升级前，使用诸如 Percona Toolkit 中的 pt-upgrade 之类的工具仔细检查系统。
- 使用 InnoDB 并进行适当的配置，确保 InnoDB 是默认存储引擎。如果存储引擎被禁止，服务器就无法启动。
- 确认基本的服务器配置是正确的。
- 通过 skip_name_resolve 禁止 DNS。
- 在未明确查询缓存有用的情况下，应该禁用查询缓存。
- 尽量避免使用复杂的特性，除非确实需要。例如复制过滤、触发器等。
- 监控重要的组件和功能。特别是像磁盘空间和 RAID 卷状态这样的关键项目。
- 尽可能久的记录服务器的状态和性能指标。
- 定期检查复制完整性。
- 将被刻意设置为只读，不要让复制自动启动。
- 定期进行查询语句审查。
- 归档并清理不需要的数据。
- 为文件系统保留部分空闲空间；
- 养成评估和管理系统的改变、状态和性能信息的习惯。
3.2 降低平均恢复时间
对于恢复时间，我们可以从三方面入手：
- 为系统建立冗余，保证系统的故障转移能力，避免单点失效。
- 为人员制定一个完善的恢复流程规范。
- 为人员组织事后复盘，避免未来发生相似的错误。
接下来，我们来讨论下具体措施。
1) 如何避免单点失效？
对于单点失效，我们首先要做的是找到它，然后针对性解决它。
一个系统中，每个单点都有可能失效。可能是一个硬盘驱动器、一台服务器或者是一台交换机、路由器，甚至某个机架的电源等等单点。
在进行相关措施前，我们要明白，单点失效并不能完全消除。我们可能引入新的的技术来解决单点失效问题，但引入的新技术可能导致更多的宕机时间。因此，我们应该按影响级别对失效单点进行排序，按照排序针对性解决单点失效问题。
具体到增加冗余的相关措施，有两种方案：增加空余容量和重复组件。
增加空余容量比较简单。可以创建一个集群或服务器池，使用负载均衡方案。这样在一台服务器失效时，其它服务器可以接管失效服务器的负载。
另外，处于很多方面的考虑可能会需要冗余组件，可以主要组件失效时，能有一个备件来随时替换。可冗余的组件可以是空闲的网卡、路由器或者硬盘驱动器等。
此外，最重要的是，要完全冗余 MySQL 服务器。这意味着我们必须确保备用服务器能够获得主服务器上的数据。可以从以下措施着手：
- 共享存储或磁盘复制
- MySQL 同步复制
2) 如何保证系统的故障转移和恢复能力？
在开始这个话题之前，我们先来认识下什么是 “故障转移”。有些人用 “回退” 表示，也有人会使用 “切换”，以表明一次计划中的切换而不是故障后的应对措施。
我们在这里使用 “故障恢复” 来表示故障转移的反面。如果系统拥有故障恢复能力，那么，故障转移就是一个双向过程：
当服务器 A 失效，服务器 B 代替它，在修复 A 服务器后可以再替换回来。
故障转移最重要的部分就是故障恢复。如果服务器间不能*切换，故障转移就是一个死胡同，只能延缓宕机时间而已。因此，使用复制时，可以使用对称复制布局，如双主结构。因为配置是对等的，故障转移和故障恢复就是在相反方向上的相同操作。
接下来我们就认识一些比较普遍的故障转移技术。
提升备库或切换角色
提升一台备库为主库，或者在一个 主-主复制结构中调换主动和被动角色，这些都是许多 MySQL 故障转移策略中很重要的一部分。详情参见MySQL 复制 - 性能与扩展性的基石 4：主备库切换
虚拟 IP 地址或 IP 接管
可以为需要提供特点服务的 MySQL 实例指定一个逻辑 IP 地址。当 MySQL 实例失效时，将 IP 地址转移到另一台 MySQL 服务器上。这里的解决方案本质上负载均衡里的虚拟 IP 技术是一样的，不同的是现在是用于故障转移。
这种方法的好处是对应用透明。它会中断已有的连接，但不用修改配置。
当然，它也有一些不足之处：
- 需要把所有的 IP 地址定义在同一网段，或者使用网络桥接。
- 有时候还需要更新 ARP 缓存。部分网络设备可能会把 ARP 信息保存太久，导致无法即时将一个 IP 地址切换到另一个 MAC 地址上。
- 需要确定网络硬件是否支持快速 IP 接管。有些硬件需要克隆 MAC 地址后才能工作。
3) 团队人员如何提高系统恢复时间？
由于团队内每个人对于宕机恢复的熟练度和对应能力各有不同，因此我们还需要一个对应人员的流程规范，来帮助大家都能在宕机时参与进来，降低系统的恢复时间。
系统恢复后，我们就要组织大家对对宕机时间进行评估，这里要注意的是，不要对此类的 “事后反思” 期望太高。导致宕机的原因通常是多方面的的，我们很难去回顾问题当时所处的状况，也很难找到真正的原因。因此，我们在事后反思得到的结论应该有所保留。
4 总结
- 可用性用宕机时间 n 个 9 来衡量。
- 实现可用性从平均失效时间和平均恢复时间入手。