MySQL - 高可用性：少宕机即高可用？

我们之前了解了复制、扩展性，接下来就让我们来了解可用性。归根到底，高可用性就意味着 "更少的宕机时间"。

老规矩，讨论一个名词，首先要给它下个定义，那么什么是可用性？

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 来衡量。
实现可用性从平均失效时间和平均恢复时间入手。