登录
首页 >  数据库 >  MySQL

MySQL - 高可用性:少宕机即高可用?

来源:SegmentFault

时间:2023-02-24 21:42:39 440浏览 收藏

数据库小白一枚,正在不断学习积累知识,现将学习到的知识记录一下,也是将我的所得分享给大家!而今天这篇文章《MySQL - 高可用性:少宕机即高可用?》带大家来了解一下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. 实现可用性从平均失效时间平均恢复时间入手

好了,本文到此结束,带大家了解了《MySQL - 高可用性:少宕机即高可用?》,希望本文对你有所帮助!关注golang学习网公众号,给大家分享更多数据库知识!

声明:本文转载于:SegmentFault 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>
评论列表