我们研究了复制、可伸缩性，现在让我们看看可用性。归根结底，高可用性意味着“更少的停机时间”。老规矩，讨论名词，首先要给它下个定义，那么什么是可用性呢？1什么是可用性我们常见的可用性通常用百分比来表示，这本身就有其隐藏的含义：高可用性不是绝对的。换句话说，100%的可用性是不可能实现的。是的，这里可以肯定地说。我们一般用“9”这个数字来描述可用性。X9表示数据中心1年运行期间，各系统正常使用时间占总时间（1年）的比例。例如：“5个9s”表示99.999%，那么应用宕机时间t：(1-99.999%)360024*365=315.36s=5.256m因此，我们可以说“5个9s”表示应用每年只允许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监控信息。例如，缓存命中率告警可能只是误报，并不代表有问题。结果，我们认为监控系统没有用，而忽略了真正的问题警报。老板问你为什么磁盘满了还没有收到报警信息就一脸无辜的看着他。因此，只要我们多做一些有针对性的工作，就可以避免很多停机时间。以下是如何开始：测试恢复工具和过程，包括从备份中恢复数据。遵循最小特权原则。保持系统干净整洁。使用良好的命名和组织约定以避免混淆。例如，服务器是用于开发环境还是生产环境。仔细安排数据库服务器升级。在升级之前，使用PerconaToolkit中的pt-upgrade等工具仔细检查您的系统。使用InnoDB并对其进行适当配置，确保InnoDB是默认存储引擎。如果存储引擎被禁用，服务器将无法启动。确认基本服务器配置正确。通过skip_name_resolve禁用DNS。如果不清楚查询缓存是否有用，则应禁用查询缓存。除非你真的需要，否则尽量避免使用复杂的功能。示例包括复制过滤器、触发器等。监控重要组件和功能。特别重要的项目，如磁盘空间和RAID卷状态。尽可能长时间地记录服务器状态和性能指标。定期检查复制完整性。将有意设置为只读，不允许复制自动启动。定期执行查询语句审查。归档和清理不必要的数据。为文件系统预留一些空闲空间；养成评估和管理系统变更、状态和性能信息的习惯。3.2减少平均恢复时间对于恢复时间，我们可以从三个方面着手：为系统建立冗余，保证系统的故障转移能力，避免单点故障。制定完善的人员恢复流程规范。组织人员事后回顾，避免以后再犯类似错误。接下来，让我们讨论一下具体措施。1）如何避免单点故障？对于单点故障，我们首先要做的是发现它，然后有针对性地解决。在系统中，每个单点都可能失败。它可以是单个点，例如硬盘驱动器、服务器、交换机、路由器，甚至是机架的电源。在采取相关措施之前，我们需要明白单点故障是无法完全杜绝的。我们可能会引入新技术来解决单点故障问题，但引入的新技术可能会导致更多的停机时间。因此，我们应该按照影响程度对单点故障进行排序，按照排序解决单点故障问题。具体到增加冗余的相关措施，有两种选择：增加备用容量和复制组件。添加备用容量相对简单。可以创建一个集群或服务器池以使用负载平衡解决方案。这样，当一台服务器发生故障时，其他服务器可以接管发生故障的服务器的负载。另外，出于多方面的考虑，可能需要冗余的部件，这样当主要部件出现故障时，可以随时有备件替换。冗余组件可以是备用网卡、路由器或硬盘驱动器。此外，最重要的是，完全冗余的MySQL服务器。这意味着我们必须确保备用服务器可以获取主服务器上的数据。可以从以下措施入手：共享存储或磁盘复制MySQL同步复制2）如何保证系统的故障转移和恢复能力？在开始这个话题之前，我们先来了解一下什么是“failover”。一些使用“fallback”而另一些使用“switchover”来指示计划的切换而不是故障后响应。我们在这里使用“failback”来表示与故障转移相反的意思。如果系统具有故障恢复能力，那么故障转移是一个双向过程：当服务器A发生故障时，服务器B取代它，并且可以在服务器A修复后被替换。故障转移最重要的部分是故障恢复。如果服务器不能自由切换，故障转移就是死路一条，只能拖延宕机时间。因此，在使用复制的时候，可以采用对称的复制布局，比如双主结构。由于配置是对等的，故障转移和故障恢复是相反方向的相同操作。接下来，我们将认识一些更常见的故障转移技术。提升备用或切换角色将备用服务器提升为主服务器，或在主-主复制结构中交换主动和被动角色，是许多MySQL故障转移策略的重要组成部分。详见MySQLReplication-性能和可扩展性的基石之四：切换虚拟IP地址或主备IP接管，可以为需要提供特色服务的MySQL实例指定一个逻辑IP地址。当MySQL实例发生故障时，IP地址将转移到另一台MySQL服务器。这里的解决方案和负载均衡中的虚拟IP技术本质上是一样的，不同的是现在是用来做failover的。这种方法的好处是它对应用程序是透明的。它在不更改配置的情况下断开现有连接。当然，它也有一些缺点：需要将所有IP地址都定义在同一个网段，或者使用网桥。有时还需要更新ARP缓存。有些网络设备可能会将ARP信息保存太久，导致无法立即将一个IP地址切换到另一个MAC地址。需要确定网络硬件是否支持快速IP接管。某些硬件需要克隆MAC地址才能工作。3)团队成员如何改进系统恢复时间？由于团队中每个人对宕机恢复的熟练程度和相应的能力不同，我们也需要相应人员的流程规范，帮助大家参与宕机，减少系统恢复时间。系统恢复后，我们会组织大家对停机时间进行评估。这里需要注意的是，不要对这种“事后诸葛亮”抱有太大期望。停机通常有很多原因。我们很难回顾问题当时的状态，也很难找到真正的原因。因此，我们事后得出的结论应该有所保留。4总结可用性是用n个9的停机时间来衡量的。实现可用性始于平均无故障时间和平均恢复时间。
