简介
数据库中断问题对每个人来说都是一个压力重重的事件。用户会感到沮丧，担心数据可能会丢失，开发人员会争先恐后地寻找原因，而公司利益相关者则会计算每一分钟可能造成的收入损失。
在发生中断时，使数据库恢复健康状态是首要任务。然而，在如此紧张的事件中，甚至很难推断出问题可能是什么。本文旨在帮助您了解数据库可能宕机的一些最常见原因以及如何解决这些问题。
本文涵盖了处理数据库中断时需要注意的各个领域，包括：
| 问题 | 潜在问题 | 操作 |
|---|---|---|
| 数据库似乎不接受连接 | 数据库用户凭据问题、连接字符串问题、连接限制已达到 | 检查数据库服务器日志以确定原因 |
| 网络通信似乎受损 | 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 筛选列表，那么数据量的差异可能会是天文数字。
在相对较小的总数据量下，这种不充分的查询可能不会被发现。随着数据量的增长，性能下降可能会变得明显，但可能不会完全破坏应用程序。然而，在这种情况下，数据库服务器将超出其可能配置的负载。随着数据量进一步增长，可能会达到一个临界点，数据库服务器将无法再处理负载。
应用服务器
就像数据库服务器没有无限容量来处理大量数据一样，应用服务器也是如此。您可能对应用服务器的容量和大小有更多的控制权，而不是对数据库服务器的控制权，但增加应用服务器的容量可能是不必要的。
从数据库服务器返回的大量数据需要时间和资源在应用服务器上进行处理。如果应用服务器正在响应来自客户端应用程序的请求，那么在应用服务器上的长时间等待可能会出现问题。许多云托管提供商会在几分钟后强制执行请求超时。网络浏览器会在请求处于“挂起”状态几分钟后自动重试请求，这会进一步增加系统的负担。
客户端
客户端应用程序最容易受到大数据量造成的瓶颈的影响。与应用服务器和数据库服务器不同，您可能无法增加其容量，而运行在浏览器或移动设备上的客户端应用程序则受到浏览器、操作系统或两者的限制。
向客户端应用程序发送过多的数据量会导致处理延迟，并严重降低响应速度。一旦达到给定的数据大小，浏览器可能会完全无响应并最终崩溃。
如果大量数据从数据库一直转发到客户端，那么在每一个步骤中都会感受到性能下降。这种三管齐下的影响将导致加载时间过长，并可能在任何一个点上导致感知到的停机。更糟糕的是，排查瓶颈所在变得困难。
数据大小补救措施
解决由数据量问题导致的性能下降和中断的方法几乎总是限制从数据库服务器返回的数据量。这样做将减轻数据库服务器、应用程序服务器和客户端的问题。
使用 WHERE 子句限定数据范围
在上面的虚构查询示例中，查询了数据库的整个联系人表。这意味着数据库服务器需要将整个表扫描到内存中，然后才能过滤到所需的结果，这可能会给数据库服务器和应用程序服务器带来巨大的负载。
首先查找范围过广的查询。这些查询很可能在数据库服务器上花费了很长时间进行处理。查看长时间运行查询的日志可以提供发生这种情况的指示。不要返回大量结果然后使用应用程序代码过滤它们，而是构建您的查询以返回真正需要的结果子集。在 SQL 中，使用 WHERE 子句来精确指定您实际需要的数据。
使用 LIMIT 和 OFFSET 分页数据
如果客户端应用程序确实需要大量数据，建议引入分页。
分页是一种设计模式，它限制了在给定时间查询和返回的记录总数。如果用户想查看更多记录，他们必须明确请求。
此设计模式最常使用 LIMIT 和 OFFSET 子句实现。通过选择跳过一定数量的记录并限制返回结果的数量，客户端和应用程序服务器可以实现分页体验。
第一页的查询可能如下所示：
第二页的查询只需将 LIMIT 的值设置为 OFFSET 值即可获取下一“页”。
排查数据量问题
大多数数据库都提供有助于排查数据量问题的工具。特别是，许多数据库提供 EXPLAIN 命令，该命令将显示查询的执行计划并提供对任何相关问题的深入了解。
例如，在 PostgreSQL 中，EXPLAIN 命令显示了正在考虑的语句的查询计划，并显示了估计的执行成本。这是查询运行所需时间的估计。
此信息有助于缩小导致瓶颈的特定表或查询语句的范围。
除了手动调用 EXPLAIN 命令之外，许多云数据库提供商还提供一种自动可视化导致问题的查询的方法。此信息通常可以在云提供商的“慢查询”视图中找到。检查数据库提供商的慢查询部分，以找出哪些查询可能对您的应用程序产生不利影响。
添加索引
与大数据量相关的问题通常可以通过使用索引来解决。
数据库表的索引可以像书中的索引一样概念化。如果您正在书中查找特定主题的信息，则需要很长时间才能通读整本书才能找到它。相反，您可以查阅索引以查找感兴趣的特定主题。如果存在，它将指向书中讨论该主题的特定页面。
同样的概念也适用于数据库索引。根据常见的访问模式为数据库表添加索引可以实现快速查找。
例如，如果您有一个用户数据库表，其中包含一个用于 email 的列，并且该表是根据用户的电子邮件查询的，那么为该表创建一个基于 email 列的索引有助于提高性能。如果没有索引，将扫描整个表以通过电子邮件地址查找用户。如果表大小非常大，这可能会导致显着的性能问题。但是，如果为该列创建了索引，则查找将很快，因为搜索特定电子邮件将立即指向所需的精确行。
向数据库添加索引需要规划和考虑，并且应该在您的数据库导致应用程序中断之前完成。但是，如果您能找到导致中断的特定查询或查询，那么添加索引以立即缓解压力会很有帮助。
破坏性代码更改
可疑的数据库中断可能是由于最近对客户端或服务器代码进行的破坏性更改造成的。在这些情况下，很可能不是数据库本身发生了中断，而是用于检索数据、处理数据并将其返回给客户端的代码可能已损坏。
可能导致中断的代码更改通常分为三类：
- 数据库查询
- 服务器代码
- 客户端代码
数据库查询
对数据库查询的更改，即使很小，也会影响应用程序。如果使用原始 SQL，查询语句可能在最近的代码更改中变得无效。如果查询本身仍然有效，它可能已被更改为返回应用程序其他部分无法再处理的结果。
检查源代码控制更改，以查找最近对数据库访问（SQL 语句或 ORM 使用）的更改。尝试隔离与受影响应用程序特定区域相关的查询。
如果没有迹象表明数据库访问发生了更改，则另一种可能性是数据库模式已更改，但尚未运行迁移。查找可能仍需要应用于生产数据库的任何最新迁移。
客户端和服务器代码
对客户端或服务器中的应用程序代码进行更改，即使很小，也可能导致看起来像是数据库中断的问题。问题根源可能有很多具体问题，但一些示例包括：
- 客户端可能正在调用不再存在的服务器端点
- 服务器端点已更改有效负载或查询参数的验证规则
- 服务器正在尝试访问从最近模式更改中失效的返回数据的属性
结论
数据库中断，无论其根本原因是什么，都可能是非常紧张的事件。在急于使应用程序恢复运行的过程中，可能很难正确地推断出数据库问题可能源自何处。
每次数据库中断都是独特的，在发生中断时没有一劳永逸的解决方案。但是，精通可能的问题及其相关的解决方案可以帮助您更有效地确定问题原因，并缩短恢复运行所需的时间。
与大多数问题解决一样，最好在问题发生之前熟悉其潜在的解决方案。我们希望本指南能帮助您实现这一目标。
Ryan Chenkie
Ryan 是一名全栈开发人员，对数据库和 API 特别感兴趣。他是 CourseLift 的创始人，这是一个课程托管平台，旨在帮助作者进行营销和销售。