简介
疑似数据库中断对于每个人来说都可能是一件压力很大的事件。用户变得沮丧，担心他们的数据可能会丢失，开发人员争先恐后地寻找原因，而公司利益相关者则计算着每一分钟可能造成的收入损失。
在发生中断事件时，让您的数据库恢复到健康状态是首要任务。但是，在如此紧张的事件中，甚至很难推断问题可能是什么。本文旨在帮助您了解数据库可能宕机的一些最常见原因以及您可以采取哪些措施来解决它。
本文涵盖了处理数据库中断时需要查找的各种领域，包括
| 问题 | 潜在问题 | 操作 |
|---|---|---|
| 数据库似乎不接受连接 | 数据库用户凭据问题、连接字符串问题、达到连接限制 | 检查数据库服务器日志以确定原因 |
| 网络通信似乎受损 | 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 时，您需要配置防火墙以允许从应用程序访问数据库。
虽然某些防火墙策略使用黑洞策略来静默丢弃不允许的流量，但其他策略会发送拒绝响应，这可以帮助您确定防火墙是否是连接中断的原因。同样，如果您遇到“没有到主机的路由”类型的错误，则可能意味着网络段已关闭或路由逻辑不正确。
此外，如果您的应用程序的 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 是一个课程托管平台，可帮助作者进行营销和销售。