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 总结

1. 可用性用宕机时间 n 个 9 来衡量。
2. 实现可用性从平均失效时间和平均恢复时间入手。