第2章 可靠性工程世界中的监控

        上一篇《第1章-8 转换存储引擎》，接着看第二章。

        监控系统是一个广泛的主题，在过去的几年中，这个主题很大程度上是由两本开创性的著作所塑造的，它们是《SRE：Google运维解密》（Site Reliability Engineering[Book]）及其后续著作《Google SRE工作手册》。

        自从这两本书出版以来，网站可靠性工程师（SRE）的公开招聘已经成为一个流行趋势。一些公司甚至将现有员工重新命名为某种“可靠性工程师”。

        网站可靠性工程改变了团队对运营工作的思考方式。这是因为它包含了一系列的原则，使我们能够更容易地回答诸如下面这样的问题：

        ● 我们提供的是可接受的客户体验吗？

        ● 我们应该关注可靠性和可恢复性工作吗？

        ● 我们如何平衡新功能和工作量？

        本章期望读者理解这些原则是什么。如果你还没有读过上述任何一本书，建议将《GoogleSRE工作手册》的这几章作为速成课程：

        ● 第1章，帮助我们更深入地理解生产中迈向服务水平性能管理背后的哲学。

        ● 第2章，介绍了如何实现服务水平目标（SLO）。

        ● 第5章，介绍了服务水平目标中的警报。

        有些人可能会争辩说，严格来说，SRE实现并不是高性能MySQL的一部分，但我们不同意。Nicole Forsgren博士在她的Accelerate （ Nicole Forsgren，Accelerate：The Science of Lean Software and DevOps（IT Revolution Press，2018））一书中说：“我们的衡量方法应该关注结果，而不是输出”。有效管理MySQL的一个关键点在于对数据库的健康状况进行良好的监控。传统的监控是一条相对平坦的道路。由于SRE是一个新的领域，人们不太了解如何在MySQL中实现SRE原则。随着SRE原则持续得到认可，DBA的传统角色将不断改变，这包括DBA对监控系统的思维方式。

可靠性工程对DBA团队的影响

        多年来，监控数据库性能依赖于对单服务器性能的深入研究。这么做仍然有很大的价值，但更多的是对被动响应的度量，比如对性能较差的服务器进行分析。在以前DBA团队作为守门人的年代，这是标准的操作程序，当时是不允许其他人知道数据库是如何操作的。

        自谷歌引入可靠性工程以来，DBA的角色变得更加复杂，更像是网站可靠性工程师（SRE）或数据库可靠性工程师（DBRE）。团队必须优化他们的时间。服务级别帮助你定义客户满意的程度和标准，以便你在解决性能、可扩展性挑战等事情与开发内部工具之间做出时间权衡。让我们讨论一下监视MySQL以确保成功的客户体验所需的不同方法。

定义服务水平目标

        在讨论如何衡量客户对数据库集群的性能是否满意之前，我们必须首先知道目标是什么，并使用通俗的说法来表述这些目标。这里有一些问题，可以作为组织中确定这些目标的引导话题：

        ● 衡量成功的合理指标是什么？

        ● 客户和我们的业务需求可以接受这些指标的哪些值？

        ● 在什么情况下会被视为处于降级状态？

        ● 什么时候处于完全失败的状态，需要尽快补救？

        在某些情况下这些问题的答案是显而易见的（例如，源数据库故障，此时无法进行任何写入操作，这会导致业务暂停运作）。在某些情况下则不那么明显，比如周期性任务有时会占用所有数据库磁盘I/O，这会让其他任务突然变慢。在整个组织中，对正在测量的内容和原因有一个共同的理解，可以帮助指导关于团队优先事项的讨论。在整个组织中通过持续讨论达成共识，有助于指导你是否应在新特性上花费精力，或者是否需要在性能改进或稳定性方面投入更多。

        在SRE实践中，这些关于客户满意度的讨论将使团队在服务水平指标（SLI）、服务水平目标（SLO）和服务水平协议（SLA）方面就什么对业务有益达成一致。让我们从定义这些术语的含义开始。

服务水平指标（SLI）

        简单地说，SLI回答了“如何衡量客户是否满意”的问题。从用户的角度来看，答案代表了一个健康的系统。SLI可以是业务级别的指标，如“面向客户的API的响应时间”或是最基本的“服务已启动”。根据数据的上下文及其与产品的关系，你可能会发现需要不同的指标。

服务水平目标（SLO）

        SLO回答了“为了确保客户满意，能允许SLI达到的最低限度是多少”的问题。SLO是我们希望将特定的SLI视为健康服务的目标范围。如果SLI的指标是服务正常运行的时间，那么在给定的时间范围内，运行时间达到几个9就是SLO。SLO必须定义为给定时间范围内的一个具体值，以确保每个人都对SLO的含义保持一致的理解。SLI加上SLO构成了了解客户是否满意的基本方程式。

服务水平协议（SLA）

        SLA回答了“我同意的SLO会产生什么后果”的问题。SLA是与一个或多个业务客户（付费客户，而非内部利益相关者）签订的协议中包含的SLO，如果未满足该SLA，将受到财务或其他处罚。请务必注意，SLA是可选的。

        本章不会详细介绍SLA，因为它们往往需要更多的业务讨论而不是工程讨论。这类决策主要取决于如果业务部门在合同中承诺SLA，他们希望获得什么样的销售业绩，以及如果SLA被破坏，是否值得冒收入损失的风险。希望通过在这里介绍的关于选择SLI和匹配SLO的内容，可以帮助你做出类似的决定。

        定义这些SLI、SLO和SLA不仅可以引导业务健康状况，还可以指导工程团队的规划。如果团队没有达到其承诺的SLO，则不应继续进行新特性的工作。数据库工程团队也是如此。如果我们在本章中讨论的某个潜在的SLO没有得到满足，那么应该引发关于为什么不满足的讨论。当有了数据来解释为什么客户体验不是最理想的，便可以就团队的优先事项进行更有意义的讨论。

怎样才能让客户满意

        选择一组指标作为SLI后，可能有人会倾向于将目标设置为100%，但你必须克制这种冲动。请记住，选择指标和目标的目的是随时使用客观指标评估团队是否能够利用新功能进行创新，或者稳定性是否有可能降至客户可接受的水平以下，因此需要更多的关注和资源。我们的目标是定义确保客户满意的最低标准。如果客户对于两秒内加载页面感到满意，则无须设置750毫秒内加载页面的目标，这会给工程团队带来不合理的负担。

        以正常运行时间作为一个指标和目标值为例，我们可以宣称“将不会有任何停机时间”，但在实现和跟踪我们是否达到目标时，这意味着什么？达到3个9的可用性就是一个不小的壮举。一年中的3个9相当于8个多小时的停机时间，转换到一周则只有10分钟。你承诺的“9”越多，就越难实现，团队为实现这一承诺所花费的工程时间也就越昂贵。表2-1是来自Amazon Web Services的一个有用的图表，以纯数字显示了挑战。

                                        表2-1：几个9的可用时间

可用性	每年停机时间	每月停机时间	每周停机时间	每日停机时间
99.999%	5 分钟，15.36 秒	26.28 秒	6.06 秒	0.14 秒
99.995%	26 分钟，16.8 秒	2 分钟，11.4 秒	30.3 秒	4.32 秒
99.990%	52 分钟，33.6 秒	4 分钟，22.8 秒	1 分钟，0.66 秒	8.64 秒
99.950%	4 小时，22 分钟，48 秒	31 分钟，54 秒	5 分钟，3 秒	43 秒
99.900%	8 小时，45 分钟，36 秒	43 分钟，53 秒	10 分钟，6 秒	1 分钟，26 秒
99.500%	43 小时，48 分钟，36 秒	3 小时，39 分钟	50 小时，32 分钟，17 秒	7 分钟，12 秒
99.250%	65 小时，42 分钟	5 小时，34 分钟，30 秒	1 小时，15 分钟，48 秒	10 分钟，48 秒
99.000%	3 天，15 小时，54 分钟	7 小时，18 分钟	1 小时，41 分钟，5 秒	14 分钟，24 秒

        工程时间是有限的资源，所以在选择SLO时必须注意不要过于追求完美。不是产品中的所有特性都需要这么多个9才能让客户满意。你会发现，随着产品特性集的增长，将会有不同的SLI和SLO，具体取决于特定功能的影响或其带来的收入。这是意料之中的，也是一个深思熟虑的过程的标志。你还有一项关键任务：检测数据集何时成为不同用户的不同查询概要文件（query profile）的瓶颈，从而影响性能。这也意味着要找到一种方法来区分不同用户的需求，以便可以为他们提供合理的SLI和SLO。

        这些指标和目标也是在产品和工程之间达成一致标准的有效方法，以指导在“将工程时间花在新功能上”与“将时间花在可恢复性和修复问题上”之间做出决策。这也是一种从需要做的事情列表中决定什么是最重要事情的方法，关键是基于用户体验来判断。你可以使用SLI和SLO来指导那些难以协调的关于工作优先级的讨论。

用什么来度量

        假设有一家公司的产品是在线商店。由于在线购物的发展，该公司未来会有更多的流量，因此需要基础设施组来确保数据库层能够处理增加的需求。在本节中，我们将讨论如果我们是虚构的基础设施团队，那么应该度量什么。

定义SLI和SLO

        定义好的SLI和匹配的SLO，是简洁地解释如何为客户提供愉快的用户体验的核心。我们不会花太多时间抽象地解释如何创建有意义的SLI和SLO。（强烈推荐Alex Hidalgo编著的Implementing Service Level Objectives一书（O'reilly出版））在MySQL的使用环境中，需要定义三大重要主题：可用性、延迟和关键错误缺失。

        以上面的在线商店为例，这种场景下的页面加载速度很快，在一个月内至少有99.5%的时间是快于几百毫秒的。这也意味着一个可靠的检查过程，在一个指定的自然月内，间歇性故障只允许1%的时间出现。注意这些指标和目标是如何定义的。我们没有要求必须做到100%，因为我们在一个不可避免失败的世界中运作。我们定义了一个时间跨度，以便团队能够在新功能和可恢复性之间准确地平衡工作。

        “我希望99.5%的数据库请求在不到两毫秒的时间内正常执行”是一个有明确SLO的充分SLI，但并不是一个简单的SLI。不应该用一个指标来确定所有要求。这只是一条简单的描述语句，表示你希望数据库层如何运行，以提供可接受的客户体验。

        那么，在在线商店的例子中，建立这种客户体验监控图的指标有什么好例子呢？从模拟测试开始，例如，在生产环境中对页面的加载速率进行取样。这是一个很有用的信号，表明“一切正常”。但这仅仅是一个开始，接下来让我们讨论通过跟踪不同方面的信号来构建一张完整的监控图。当浏览这些示例时，把它与在线商店联系起来，以直观地了解这些不同的指标如何构成一张良好的客户体验监控图。首先，让我们讨论一下跟踪查询响应时间。

监控解决方案

        在SLI和SLO的背景中，查询分析和查询延迟监控都需要关注客户体验。这意味着需要依赖一些工具，当查询响应时间超过商定的阈值时，能够第一时间发出警报。下面讨论几种实现这种监控级别的方法。

商业选项

        这是其中一个例子。如果一个供应商的竞争优势是分析MySQL性能的特定任务，那么付费是可以给组织带来回报的。诸如SolarWinds 数据库性能管理工具（参见链接6 Database Observability | SolarWinds）可以大大提高剖析查询性能的自动化程度，并且让工程组织中的大部分人都能比较容易地理解。

开源选项

Percona 监控与管理是一个成熟的开源选项（参见链接7 Redirecting），称为PMM。它以客户端/服务器的方式运行。在数据库实例上安装一个客户端，该客户端收集指标并将其发送到服务器端。服务器端还有一组仪表盘，可以查看与性能相关的图表。PMM的一大好处是，仪表盘的组织是由Percona社区在监控MySQL性能方面的长期经验指导的。这让它成为一个很好的资源，可以让刚接触MySQL的工程师熟悉如何监控MySQL性能。另一种方法是将数据库慢查询日志和MySQL Performance Schema的输出信息发送到一个集中的位置，然后可以使用像pt-query-digest（Percona Toolkit包中的工具）这样的成熟工具来分析日志，并更深入地了解数据库实例在哪些方面花费了时间。这种方法虽然有效，但此过程可能会很慢，如果使用不当，可能会影响客户。理想情况下，还是希望在客户注意到问题之前发现问题。在问题发生后再被动地检查日志，将面临客户信任下降的风险，因为发现性能倒退然后挖掘各种事后现场以确定发生了什么可能会需要很长的时间。

        最后，使用Performance Schema来分析MySQL的性能对我们会有很大帮助，在第3章你将了解到关于Performance Schema的更多细节。通过Performance Schema可以发现性能瓶颈，从而让数据库实例能在相同规格下承载更多业务压力，并节省基础设施成本，或者回答诸如“为什么要花这么长时间”这样的问题。Performance Schema并不是一个仅用于确定是否满足服务可用性承诺的工具，因为它涉及MySQL内部深层的机制。为了做好服务水平性能评估，我们现在需要一种思考性能的新方法。

关于“在生产中测试”的说明

        经常会听到“生产中测试”的鼓声，这让很多人畏缩。实际情况是，在生产中进行测试具有很大的价值。在生产中，你可以发现这种变化是如何影响系统的其他部分、规模和实际客户流量的。也可以查看对相邻系统的影响。

通过使用基本的“客户是否满意”的问题，可以看到：

        ● 当来自生产的反馈循环很快，并且和变更紧密相关时，回滚变更并重新检查正在部署的特定变更的速度也会快得多。

        ● 这种方法促进了功能团队和数据库工程师之间更强大的协作。当所有相关方都在观察特定的具体指标和它们应该是什么值时，测量性能的任务就变成了一项团队工作。

        ● 在性能倒退的情况下，花费生产之外的精力去调查“发生了什么”远比试图重新创建一个模拟更大代码路径的基准测试套件要具体得多。用于调试的工程时间变得更有针对性。

        现在，让我们深入了解其他指标，以进一步理解在线商店的客户体验。你应该考虑从MySQL中获得的结果，而不是输出。我们还将介绍一些无法仅通过MySQL指标来测量的情况。

监控可用性

        间歇性不可用的在线商店会降低购物者的信任。这就是为什么将可用性作为一个独立的指标，以及作为客户体验中如此重要的一部分。

        可用性是指能够无错误地响应客户的请求。要用标准HTTP术语来描述这一点，要么是一个明确成功的响应，如200响应代码，要么是一个成功接受请求并承诺异步完成相关工作的响应，如202已接受。在单机系统的时代，可用性曾经是一个简单的指标。如今，大多数架构都十分复杂，可用性的概念已经演变为分布式系统如何失效的更细微的反映。当试图将可用性转换为数据库架构的SLI和SLO时，请考虑进一步的细节（结合在线商店的示例），例如：

        ● 在处理不可避免的灾难性故障时，哪些功能是不可协商的，哪些功能是“最好拥有的”（例如，客户是否可以继续使用现有购物车并下单，只是在此故障期间不能添加新商品）？

        ● 将哪些类型的失败定义为“灾难性的”（例如，列表搜索失败可能不是灾难性的，但下单操作失败将是灾难性的）？

        ● “降级功能”是什么样子的（例如，是否可以在需要时加载通用推荐，而不是基于过去的购买历史加载定制化推荐）？

        ● 给定一组可能的故障场景（例如，如果支持购物车下单系统的数据库写入失败，可以以多快的速度安全地转换到新的主节点），可以为核心功能承诺的最短平均恢复时间（MTTR）是多少？

        当选择一组指标来表示可用性时，如果你想要与客户支持团队一起设定“100%正常运行时间”的期望，这是不合理的，这里的重点是，在理解并接受组件故障不可避免的情况下，尽可能地提供最好的客户体验。

        验证可用性的首选方法是从客户端或远程端点来进行访问。如果可以访问客户端记录的数据库访问日志，则可以被动地执行此操作。明确地说，这意味着如果是PHP应用程序，并且在Apache下运行，那么需要访问Apache日志，以确定PHP在连接到数据库时是否发出任何错误。你也可以主动验证可用性。如果环境是隔离的，无法访问客户端日志，那么可以考虑设置远程代码并在数据库执行操作，以确保数据库可用。这可能很简单，比如SELECT 1这样的查询，可以验证MySQL是否正在接收和解析查询，但不需要访问存储层。也可能更复杂一点，比如从表中读取实际数据，或者执行写操作然后再读取以验证写操作是否成功。这种来自异地网络访问的模拟事务可以让你了解应用程序是否可用。

        可用性的远程验证对于跟踪可用性目标非常有用，但它不能让你在问题出现之前就发现。MySQL中有一个Threads_running状态计数器可以作为可用性问题的关键指标，这个计数器跟踪的是给定数据库主机上当前正在运行的查询数量。当运行的线程快速增长且没有任何下降迹象时，说明查询完成得不够快，因此正在堆积和消耗资源。如果允许这个指标增长，通常会导致数据库主机出现完全的CPU锁定或严重的内存负载，从而导致操作系统关闭整个MySQL进程。如果这种情况发生在主节点上，显然会导致重大的中断，所以应该将其视为关键指标。要监控这一点，首先要检查有多少个CPU核，如果Threads_running超过了CPU核数，则可能表明服务器正处于不稳定状态。与此相结合，你还可以监控Thread_running与max_connections的差距，将此差距作为另一个数据点，以检查正在进行的工作是否过载。

        在第5章的“安全设置”一节中，我们将深入了解如何遏制失控的MySQL线程。

监控查询延迟

        MySQL引入了许多长期需要的增强功能来跟踪查询运行时间（参见链接8 MySQL :: MySQL 8.0 Reference Manual :: 29.12.20.3 Statement Summary Tables），当更改应用程序代码时，你一定要使用监控堆栈来跟踪这些趋势。然而，这仍然不是客户体验的全貌，特别是考虑到现代软件架构的设计方式。除了内部跟踪的延迟，你还需要了解应用程序如何感知延迟，以及当感知到的延迟增加时会发生什么。这意味着，除了直接从数据库服务器跟踪查询延迟，还可以通过客户端工具来及时报告查询完成情况，从而尽可能提升客户体验。也可以使用诸如DataDog或SolarWinds数据库性能监控之类的付费工具，或者使用诸如PMM之类的开源工具，从客户端（尤其是当基础设施不断扩张时）收集所有的样本指标。在这里，与组织的应用程序开发人员密切协作至关重要。你需要了解应用程序团队如何从应用程序的角度来衡量这一点，并使用诸如Honeycomb或Lightstep之类的跟踪工具增加对异常值的关注。

监控报错

        每次报错是否都需要跟踪和提醒？这要视情况而定。

        MySQL客户端在访问运行着的服务的过程中出现错误并不一定意味着服务遭到破坏。在分布式系统的世界中，在很多情况下，客户端可能会遇到间歇性错误，通过简单地重试失败的查询就可以解决这些错误。不过，在基础架构中，对于处理数据库查询的服务而言，

        错误发生的频率可能是潜在问题的关键指标。以下是一些客户端错误的示例，这些错误通常可能只是噪声，但如果报错的频率加快，则是将要出现问题的迹象。

Lock wait timeout

        如果客户端中该报错急剧增加，可能是主节点上的行级锁争用在不断扩大，即事务不断重试但仍然失败。这可能是无法写入的前兆。

Aborted connections

        如果客户端中该报错突然激增，可能表明客户端和数据库实例之间的某个访问层出现了问题。不跟踪这一点会导致大量客户端重试，这会消耗资源。

        MySQL服务器跟踪的名为Connection_errors_xxx的服务器变量集（参见链接9 MySQL :: MySQL 8.0 Reference Manual :: 7.1.10 Server Status Variables）非常有用，其中×××是不同类型的连接错误。这些计数器的突然增加可能是一个强有力的指示器，告诉你出现了一些新的问题。

        是否存在只要在单个实例上出现即意味着麻烦并需要处理的错误呢？答案是肯定的。

        举个例子，如果MySQL实例运行在只读模式，即使这种错误不是经常发生，也是出现问题的标志。这可能意味着你已经将一个副本提升为主节点，但仍然运行在只读模式下（副本通常运行在只读模式，不是吗？），对于集群的写操作而言，这就是宕机了。或者，这可能意味着访问层出现了问题，从而将写操作发送到了副本节点。在上述任何一种情况下，这都不是通过重试就能解决的间歇性问题的标志。

        另一个作为重大问题标志的服务器端错误是“too many connections”或操作系统级别的“cannot create new thread”。这些迹象表明，应用程序创建和打开的连接数超过了数据库服务器配置中允许的连接数，这个限制可能来自服务器的max_connections变量或者MySQL进程被允许打开的线程数。这些错误会立即转化为5××错误返回给应用程序，这会对客户产生影响，具体取决于应用程序的设计。

        如你所见，衡量性能和选择哪些错误来构建SLI既是一个技术问题，也是一个沟通和社交问题，你应该为此做好准备。

主动监控

        正如我们所说，SLO监控的重点是客户是否满意。这有助于你在客户不满意的时候专注于改善他们的体验，在客户满意的时候可以专注于其他任务，比如减少工作量。但这忽略了一个关键点：主动监控。

        回到在线商店的例子，设想一下我们要如何监控客户的体验。假设没有遇到任何组件的重大故障，但注意到反馈“缓慢”或偶尔出现错误的客户支持工单正在上升。你如何跟踪这种行为？如果不知道许多信号的基线性能是什么，那么这可能是一项非常困难的任务。用于触发随叫随到（on-call）告警的仪表盘和脚本被称为稳态监控。无论是否有变更，这些告警会让你知道某个系统发生了意外情况，也是在客户体验失败之前提供前导指标的重要工具。

        监控方面需要达到的平衡是，它既要具有可操作性，又要成为真正的前导指标。数据库磁盘100%满时的空间告警已经太迟了，因为服务已经停止。但如果磁盘空间占用的增长速度没那么快，设置磁盘空间超过80%就发出告警的话，可能还不需要急着采取行动，告警可能会被忽略。

        让我们来讨论一下可以监控的有用信号，这些信号与实际的客户影响没有直接关系。

磁盘空间使用率增长

        在出现问题之前，跟踪磁盘空间使用率的增长可能是一类不太会被考虑的指标。而这个问题真的出现时，解决起来会耗费时间并影响业务。最好还是了解如何跟踪该指标，制订缓解计划，并知道告警阈值设置成多少是合适的。

        有许多策略可用于监控磁盘空间使用率的增长。让我们从最理想到最简单的方式来拆解一下。

        如果监控工具允许，那么跟踪磁盘空间使用率的增长速度将非常有用。总会有这样的场景，可用磁盘空间可能被快速耗尽，从而使可用性面临风险。诸如伴随大量Undo日志的长时间运行的事务或alter table之类的操作是导致磁盘空间快速耗尽的原因。有很多这样的事故，在数据库耗尽磁盘空间之前，过度的日志记录或者对某些数据集的插入模式的变化这样的情况都没有被检测到。直到磁盘耗尽之后，各种告警才发出来。

        如果跟踪增长率不可行（并非所有监控工具都提供此功能），则可以设置多个阈值，其中较低的警告可以设置为仅在工作时间触发，而较高的、更严重的值则作为对非工作时间随叫随到的告警。这使得团队可以在工作时间提前处理告警，以免事情变得糟糕到半夜把人惊醒。

        如果既不能监控增长率，也不能为同一指标定义多个阈值，那么至少需要确定用于呼叫随叫随到（on-call）工程师的单个磁盘空间阈值。这个阈值需要足够低，以便在团队评估触发的原因并考虑长期缓解措施时，有时间执行释放磁盘空间和其他一些操作。可以考虑计算磁盘可以写入的最大吞吐量（M B/s），并用它来计算在最大吞吐量下填满磁盘需要多长时间，你需要这么长的准备时间来避免发生事故。

        我们将在第4章讨论操作系统和硬件配置，会涉及MySQL如何使用磁盘空间以及在与磁盘空间增长相关的决策中应考虑哪些取舍。可以预料的是，在某个时候，业务可能会增长到无法将所有数据存储在一个服务器集群中。即使运行在可以扩展卷的云环境中，仍然需要对此进行规划，设置一个可用磁盘空间的阈值，以便有足够的时间来计划和执行所需的扩展，而不会感到恐慌。

        这里的要点是确保有一些对于磁盘空间增长的监控，即使你认为现在还为时过早，不需要它。这是几乎让所有人措手不及的增长率之一。

连接数增长

        随着业务的增长，普遍现象是应用程序层的线性增长。你将需要更多的应用实例来支持登录、购物车、处理请求或产品的任何功能。添加的这些实例开始打开越来越多到数据库主机的连接。你可以通过添加副本、使用复制作为扩展措施，甚至使用ProxySQL之类的中间件层，将前端的增长与数据库上的连接负载直接解耦，从而在一段时间内缓解这种增长。

        当流量不断增长时，数据库服务器可以支持有限的连接池，这被配置为服务器参数max_connections。一旦与服务器的连接总数达到最大值，数据库将不允许任何新的连接，这是导致无法与数据库建立新连接的常见原因，从而会导致用户感知的错误增加。

        监控连接数增长是为了确保资源不会耗尽到危及数据库可用性的程度。这种风险可能以两种不同的方式出现：

        ● 应用程序层打开了大量未使用的连接，导致产生了毫无理由的连接过多的风险。一个明显的迹象是连接的线程数（threads_connected）很高，但运行的线程数（threads_running）仍然很低。

        ● 应用程序层正在积极地使用大量的连接，并有导致数据库过载的风险。可以通过查看连接的线程数（threads_connected）和运行的线程数（threads_running）都处于高值（成百上千？）并持续增加来识别这种状态。

        在设置连接数监控时，要考虑的一个有用的技巧是依赖百分比而不是绝对值。

        threads_connected/max_connections的比值显示了应用程序节点数量的增长与数据库允许的最大连接池有多接近。这有助于监控连接数增长问题的第一个状态。

        另外，还需要对数据库主机的繁忙程度进行跟踪并设置告警，正如前面解释的，这可以从threads_running的值中看出。通常，如果这个值增长到100以上，就会开始看到CPU使用率和内存使用率的增加，这是数据库主机上高负载的普遍迹象。对于数据库可用性来说，这是需要立即关注的问题，因为它可能导致MySQL进程被操作系统杀死。一个常见的快速解决方案是使用杀死进程命令或自动化使用该命令的工具，如pt kill，从战术上减轻负载，然后使用查询分析（前面已经描述过）研究数据库为什么会进入这种状态。

警告：

        连接风暴是指在生产系统中，应用程序层感知到查询延迟增加，并通过打开更多到数据库层的连接进行响应的情况。这可能会导致数据库负载显著增加，因为它要处理大量涌入的新连接，这会占用执行查询请求的资源。连接风暴可能导致max_connections中的可用连接突然减少，并增加数据库可用性的风险。

小结：

        平时开发中，监控报错是非常必要的，尤其注意锁表；主动监控中，磁盘使用率的增长也要留意。

         上一篇《第1章-8 转换存储引擎》

         下一篇《第1章-8 转换存储引擎》