简介
疑似数据库中断对于每个人来说都可能是一件压力很大的事件。用户会感到沮丧并担心他们的数据可能会丢失，开发人员争先恐后地寻找原因，而公司利益相关者则计算每一分钟可能造成的收入损失。
在发生中断时，使您的数据库恢复到健康状态是首要任务。但是，在如此紧张的事件中，甚至很难推断问题可能是什么。本文旨在帮助您了解数据库可能宕机的最常见原因以及您可以采取哪些措施来解决问题。
本文涵盖了处理数据库中断时需要查看的各个领域，包括
| 问题 | 潜在问题 | 操作 |
|---|---|---|
| 数据库似乎不接受连接 | 数据库用户凭据问题、连接字符串问题、达到连接限制 | 检查数据库服务器日志以确定原因 |
| 网络通信似乎受损 | VPC 和防火墙问题，应用程序和数据库之间的延迟和超时 | 检查防火墙规则，查找延迟和超时，检查是否达到连接限制 |
| 数据库服务器或应用程序服务器崩溃 | 潜在的数据量问题导致数据库服务器和应用程序服务器达到资源限制 | 查找大量返回的数据，优化查询，添加索引 |
| 数据库服务器已启动，但应用程序未显示数据 | 潜在的近期代码更改，包括模式更改、未应用的迁移、格式错误的查询 | 检查源代码控制历史记录以查找近期更改，并在必要时回滚 |
阅读本文的最佳时间是在数据库宕机之前很久。如果您的数据库已经宕机，那么次佳时间就是现在。
数据库连接问题
从应用程序日志中寻找线索
如果您的数据库似乎已关闭，则您的应用程序日志可能会让您深入了解任何接受请求或连接到数据库的问题。由于应用程序服务器同时处理客户端请求和对数据库的请求，因此如果数据库存在问题，它通常会记录错误。
如果您正在使用 Prisma Client，您可以配置日志记录以控制日志的生成方式。
应用程序服务器是否成功处理连接？
公开 API 并通过查询数据库来服务请求的应用程序服务器有两种连接类型
- 用户对应用程序服务器公开的 API 的请求
- 应用程序服务器对数据库的请求
在调试中断时，请记住，两种连接类型的问题都可能导致中断。
应用程序服务器框架通常带有内置的日志记录器。一旦服务器启动，记录服务器可以接受连接是一种常见的做法。
例如，看一下此日志行
日志显示服务器已启动并在端口 8000 上接受连接。但这不足以确定自服务器启动以来是否发生错误。
下一步是查看最新的日志，并检查服务器最新请求的 HTTP 状态代码。通常，请求日志将如下所示
每个传入的请求日志都包含时间戳、URL 和有关请求的其他信息。第一个日志指示传入的请求，而第二个日志显示请求成功，HTTP 状态代码为 200。
最近是否有任何数据库错误？
由于您正在尝试调试与数据库相关的问题，因此您应该专门查找失败的请求。您可以通过筛选响应状态代码为 5xx 的请求（例如，表示服务器错误的 500）来找到这些请求。
如果您注意到多个状态代码为 500 的请求，请查找这些请求开始的点，并检查是否有任何其他记录的错误。
如果数据库已关闭或数据库的凭据错误，您可以看到已记录的错误。例如
上面的日志表明您的应用程序服务器无法连接到数据库。在这种情况下，请检查应用程序服务器中的数据库 URL。
如果您正在使用 Prisma Client，则错误代码参考可以帮助诊断错误意味着什么以及如何修复它们。
数据库问题排查
现在您知道您的应用程序服务器正在运行但无法连接到数据库，下一步是确定原因。最好的方法是从排除问题的潜在来源入手。
如果您正在为数据库使用托管服务，请首先检查您的云提供商的状态页面。大多数云提供商都提供了一种检查其基础设施是否运行正常的方法，例如 Digital Ocean、Google Cloud Platform 和 AWS。
一旦您排除了云平台的任何问题，接下来要检查的是数据库实例的日志或状态。
托管数据库日志
如果您使用的托管数据库提供商似乎运行正常，那么您的下一步是检查特定数据库实例的日志。
大多数云平台都提供了一种查看数据库日志以及一些指标（例如吞吐量和查询统计信息）的方法。日志的布局和详细程度因云提供商而异。但是，大多数云提供商都提供了足够的详细程度来帮助您搜索问题。
每个云提供商也有不同的方式访问数据库日志。大多数提供商都使日志可以从部署管理页面轻松访问。
例如，DigitalOcean 提供了一个名为“日志和查询”的选项卡，可以直接从部署管理菜单访问。
此部分包含几种不同类型的日志记录信息，包括常规的“最近日志”部分。您可能会找到连接到数据库的问题或其他可能正在发生的问题的指示。
网络问题
与网络相关的问题可能会导致您的数据库不可用或看起来已关闭。在由客户端层、应用程序层（后端）和数据层（数据库）组成的三层应用程序中，网络问题可能在三层之间出现。
与网络相关的问题包括
- VPC 和防火墙策略问题
- 延迟以及应用程序和数据库之间的超时
当您的数据库似乎已关闭或无响应，并且您怀疑这可能与网络问题有关时，最好首先确定流量是否被防火墙策略阻止，或者是否存在实际的网络问题。
注意：以下建议基于可能不适用于您的架构的假设。因此，建议在调试数据库问题时了解故障模式及其原因。
VPC
在云平台上预置云资源（例如数据库）时，它们会隔离在虚拟私有云 (VPC) 中。实际上，VPC 充当应用程序资源的专用网络，并与公共互联网隔离。如果您的数据库和应用程序不在同一 VPC（或同一云）中，则通常需要配置 VPC 的防火墙规则以允许应用程序的 IP 访问数据库。
防火墙规则
当您将应用程序和数据库部署到不同的云平台或不同的 VPC 时，您需要配置防火墙以允许从应用程序访问数据库。
虽然某些防火墙策略使用黑洞策略来静默丢弃不允许的流量，但其他策略会发送拒绝响应，这可以帮助您确定防火墙是否是连接中断的原因。同样，如果您遇到“no route to host”类型的错误，则可能意味着网络段已关闭或路由逻辑不正确。
此外，如果您的应用程序的 IP 是动态的，则它可能随时更改。当应用程序的 IP 更改时，它可能无法连接到数据库，直到防火墙已更新以允许新的 IP 访问。
防火墙规则补救措施
通常最好将应用程序和数据库部署在同一 VPC 和同一区域中，以便两者通过专用网络进行通信。它还可以防止公共网络可能造成的瓶颈。但是，如果这不可能，则有几种可能的修复方法。
第一种方法是为您的应用程序使用专用 IP，并添加允许从该 IP 访问的防火墙规则。这种方法确保您无需更新防火墙规则，因为 IP 保持不变。
如果由于云平台限制或部署方法（例如，无服务器）而使用专用 IP 不可行，请考虑通过公共网络启用对数据库的访问。虽然这种方法降低了数据库的安全性，但它可以确保您的应用程序在您更新防火墙规则以应对应用程序 IP 更改之前不会遇到任何突然的停机时间。此外，您的数据库的身份验证机制仍然是主要的防御手段。
请注意，不建议从公共互联网打开与数据库的连接。在可能的情况下，我们建议将连接限制为特定的 IP 地址或使用 VPC 对等连接等技术。
延迟和超时
当应用程序和数据库之间的地理和网络距离很大时，请求延迟增加和超时错误可能成为问题。在这种情况下，可能需要在您的应用程序中增加数据库连接超时时间，以避免超时错误。
ORM 和 查询构建器 持有数据库连接池。这些连接通常具有连接超时配置，该配置控制在建立连接时超时之前等待的时间。
建议设置初始基线超时值并加载测试应用程序以查看其性能。根据负载测试中失败请求的数量，您可能需要调整超时时间并重试，直到您确信超时不是问题的原因。如果您的连接超时配置过低，则您可能会面临这些超时导致请求失败的风险。
连接限制耗尽
像 MySQL 和 PostgreSQL 这样的基于连接的数据库的另一个常见挑战是，您可能会很快耗尽数据库的连接限制。面向连接的数据库对数据库的打开连接数施加了限制。
当您使用传统的长时间运行的进程模型部署应用程序时，您可以在池中使用较少的数据库连接来多路复用许多传入的请求。例如，单个服务器实例可以使用 20 个数据库连接的池来处理 100 个并发 HTTP 请求。
但是，在 无服务器 函数上，每个函数实例一次只能处理 1 个 HTTP 请求。由于每个传入的请求都需要至少一个数据库连接，因此您无法多路复用数据库连接。
鉴于此，建议使用数据库连接限制，然后在连接到它的服务器实例之间分配这些连接，使其不会耗尽数据库的连接限制。例如，假设您的数据库的连接限制为 20。如果您有两个应用程序服务器实例，则需要将每个服务器实例的连接池设置为最多 10 个连接。
对于无服务器部署，请考虑运行外部 连接池（如 PgBouncer）——这是一个额外的基础设施组件，用于保持与数据库的连接并多路复用来自无服务器函数的传入数据库查询。
数据量问题
随着应用程序的增长，该应用程序的数据量也很可能会增长。对于性能和数据库正常运行时间而言，一个关键的考虑因素是为满足给定请求而处理的数据量。当总数据量较小时，为应用程序编写的低效查询可能会变成瓶颈，当数据增长时，这些瓶颈可能会严重降低性能并导致中断。
大数据量可能会在三个位置产生影响
- 数据库服务器
- 应用程序服务器
- 客户端
数据库服务器
当从应用程序服务器发出数据库查询时，数据库服务器的职责是检索请求的数据并将其发送回应用程序服务器。为此，数据库服务器必须首先将检索到的数据扫描到其自己的内存中。当数据量较小时，将数据扫描到内存并将其转发到应用程序服务器的过程是微不足道的。但是，如果从查询返回大量数据，则配置不足的数据库服务器可能会在负载下崩溃。
当最初在较小总数据库大小下足够的查询在数据大小增长时未得到充分优化时，通常会发生这种情况。
考虑这样一种情况：应用程序需要显示用户的联系人列表。用于提供此数据的典型数据库查询可能会选择限定于该用户的数据。
根据应用程序的需求，应用程序服务器可能除了将结果转发给客户端之外，没有其他任何事情可做。此查询不太可能导致数据量问题。
但是，考虑一下如果在上面的查询中没有 WHERE 子句会发生什么。
相反，如果查询要求数据库中所有联系人，然后应用程序服务器负责在将结果转发给客户端之前基于 userId 筛选列表，则数据量差异可能是巨大的。
在相对较小的总体数据量的情况下，这种不充分的查询可能会被忽略。随着数据量的增长，性能下降可能会变得明显，但可能不会完全破坏应用程序。但是，随着这种情况的发生，数据库服务器的负载将超出其可能配置的范围。随着数据量的持续进一步增长，可能会达到一个临界点，数据库服务器不再能够处理负载。
应用程序服务器
就像数据库服务器没有无限容量来处理大量数据一样，应用程序服务器也是如此。您可能比数据库服务器更能控制应用程序服务器的容量和大小，但增加应用程序服务器的容量可能是不必要的。
从数据库服务器返回的大量数据需要在应用服务器上花费时间和资源进行处理。如果应用服务器正在响应来自客户端应用程序的请求，则应用服务器上的长时间等待可能会成为问题。许多云托管提供商会在几分钟后强制执行请求超时。Web 浏览器会在请求处于“挂起”状态几分钟后自动重试请求，从而给系统带来进一步的压力。
客户端
客户端应用程序可能最容易受到大数据量导致的瓶颈的影响。与应用服务器和数据库服务器不同，您可能有能力增加容量，而客户端应用程序（在浏览器或移动设备中运行）会受到浏览器、操作系统或两者的限制。
向客户端应用程序发送过多的数据会导致处理延迟，并可能严重降低响应速度。一旦达到给定的数据大小，浏览器可能会完全无响应，并最终崩溃。
如果非常大的数据量从数据库一直转发到客户端，则每个步骤都会感受到性能下降。这种三重影响将导致加载时间过长，并可能在这些点中的任何一个点上出现感知到的中断。更复杂的是，故障排除瓶颈存在的位置可能会变得困难。
数据大小补救措施
解决数据量问题导致的性能下降和中断的几乎总是限制从数据库服务器返回的数据量。这样做将缓解数据库服务器、应用服务器和客户端的问题。
使用 WHERE 子句限定数据范围
在上面虚构的查询示例中，查询了数据库的整个联系人表。这意味着数据库服务器需要将整个表扫描到内存中，然后才能过滤到所需的结果，这可能会给数据库服务器和应用服务器带来巨大的负载。
首先查找撒网过宽的查询。这些查询很可能在数据库服务器上花费很长时间才能处理。查看长时间运行的查询的日志可以指示这种情况发生的位置。与其返回大量结果，然后使用应用程序代码过滤它们，不如构建查询以返回真正需要的结果子集。在 SQL 中，使用 WHERE 子句来明确您实际需要的数据。
使用 LIMIT 和 OFFSET 分页数据
如果客户端应用程序确实需要大量数据，则建议引入分页。
分页是一种设计模式，它限制了在给定时间查询和返回的记录总数。如果用户想查看更多记录，他们必须显式请求它们。
这种设计模式最常使用 LIMIT 和 OFFSET 子句来实现。通过选择跳过一定数量的记录并限制返回结果的数量，客户端和应用服务器可以实现分页体验。
第一页的查询可能如下所示
然后，第二页的查询只需将 LIMIT 的值设置为 OFFSET 值即可获得下一“页”。
数据量问题故障排除
大多数数据库都提供可以帮助排除数据量问题的工具。特别是，许多数据库都提供 EXPLAIN 命令，该命令将显示查询的执行计划，并提供对任何相关问题的见解。
例如，在 PostgreSQL 中，EXPLAIN 命令显示正在考虑的语句的查询计划，并将显示估计的执行成本。这是对查询运行所需时间的估计。
此信息有助于缩小导致瓶颈的特定表或查询语句的范围。
除了手动调用 EXPLAIN 命令之外，许多云数据库提供商还提供一种自动可视化导致问题的查询的方法。此信息通常可以在云提供商的“慢查询”视图中找到。查看数据库提供商的“慢查询”部分，以查找可能对您的应用程序产生不利影响的查询。
添加索引
与大数据量相关的问题通常可以使用索引来补救。
数据库表的索引可以像书中的索引一样概念化。如果您正在书中查找关于特定主题的信息，则需要很长时间才能通读整本书才能找到它。相反，您可以查阅索引以查找感兴趣的特定主题。如果存在，它将指向书中讨论该主题的特定页面。
相同的概念应用于数据库索引。基于常见的访问模式向数据库表添加索引可以实现快速查找。
例如，如果您有一个用户数据库表，其中包含 email 列，并且查询该表以根据用户的电子邮件查找用户，则创建基于 email 列的表的索引有助于提高性能。如果没有索引，将扫描整个表以按电子邮件地址查找用户。如果表大小非常大，这可能会产生严重的性能问题。但是，如果为该列创建了索引，则查找速度会很快，因为搜索特定的电子邮件将立即指向所需的准确行。
向数据库添加索引需要计划和考虑，并且应该在数据库导致应用程序中断之前完成。但是，如果您可以找到负责产生中断的特定查询或多个查询，则添加索引以立即缓解压力可能会有所帮助。
破坏性代码更改
可疑的数据库中断可能可以追溯到最近对客户端或服务器代码进行的破坏性更改。在这些情况下，很可能不是数据库本身遇到中断，而是用于检索数据、处理数据并将其返回给客户端的代码可能已损坏。
可能导致中断的代码更改通常分为三类
- 数据库查询
- 服务器代码
- 客户端代码
数据库查询
即使是很小的数据库查询更改也可能影响应用程序。如果使用原始 SQL，则查询语句可能在最近的代码更改中变为无效。如果查询本身仍然有效，则可能已更改为返回应用程序的其他部分不再可处理的结果。
检查源代码控制更改，以查找最近对数据库访问（SQL 语句或 ORM 用法）的更改。尝试隔离与受影响的应用程序特定区域相关的查询。
如果没有迹象表明数据库访问发生了更改，则另一种可能性是数据库架构已更改，但尚未运行迁移。查找最近可能仍需要应用于生产数据库的任何迁移。
客户端和服务器代码
客户端或服务器中应用程序代码的代码更改（即使很小）也可能导致看起来像数据库中断的情况。可能有很多具体问题是问题的根源，但一些示例包括
- 客户端可能正在调用不再存在的服务器端点
- 服务器端点已更改有效负载或查询参数的验证规则
- 服务器正在尝试访问从最近的架构更改中变为无效的返回数据中的属性
结论
数据库中断，无论其根本原因是什么，都可能是非常紧张的事件。在试图让应用程序恢复并运行的匆忙中，可能很难正确地推断数据库问题可能源于何处。
每次数据库中断都是独一无二的，并且在发生中断时没有万能的解决方案。但是，熟悉可能的问题及其相关的解决方案可以帮助您更有效地确定问题的原因，并减少恢复运行所需的时间。
与大多数问题解决一样，最好在问题发生之前熟悉潜在的问题解决方案。我们希望本指南能帮助您实现这一目标。
Ryan Chenkie
Ryan 是一位全栈开发人员，对数据库和 API 特别感兴趣。他是 CourseLift 的创始人，CourseLift 是一个课程托管平台，可帮助作者进行营销和销售。