2025-10-20，发生了一起影响 PlanetScale 的事故，最初由 PlanetScale 其中一个服务提供商的 DNS 配置错误引起，随后是数小时的容量限制和网络不稳定。该事故分为两个不同阶段，第一阶段影响 PlanetScale 控制平面，第二阶段影响托管在 AWS us-east-1 中的部分数据库分支。

我们对隔离和静态稳定性的设计关注使我们处于有利位置，能够以最小影响度过此次事故。在事故的第一阶段，我们的控制平面受到影响，但客户数据库分支仍完全可用。在第二阶段，AWS us-east-1 中的部分客户数据库分支受到网络分区影响。

第一阶段

PlanetScale 工程师在 UTC 7:13 收到控制平面问题的警报。我们在生产环境中的持续测试开始失败。这些测试覆盖 PlanetScale 的广泛功能，但此时无法创建新的数据库分支。进一步调查显示，这几乎是一次控制平面全面中断。负责创建、调整大小和配置数据库分支的服务托管在 AWS us-east-1，当时不可用。它依赖我们的内部密钥分发服务，而该服务依赖 Amazon S3，Amazon S3 又依赖 AWS STS，而 AWS STS 受到 Amazon DynamoDB 中断的影响。

在此期间，没有任何数据库分支失去容量或连接性。

在事故的这一阶段，PlanetScale 仪表盘间歇性可用。它由某个提供商托管，而该提供商与 PlanetScale 控制平面一样托管在 AWS us-east-1。此外，使用 SSO 的 PlanetScale 客户如果尚未登录，则无法登录。

最后，在这一阶段，我们无法向 https://planetscalestatus.com 发布更新，不过即使能够发布，该网站本身也至少半小时不可用。

PlanetScale 工程师进行了彻底调查，但在事故的这一阶段没有采取任何纠正措施。在上游服务提供商恢复后，服务于 UTC 9:30 恢复。

第二阶段

大约半小时后，在 UTC 10:05，PlanetScale 工程师收到警报，称我们在某个客户大型单租户安装中的一个 Kubernetes（容器编排平台） 容器编排平台 operator 正在耗尽所有可用资源。这通常意味着延迟增加，或控制平面请求失败并正在重试。响应人员很快确认，我们无法在 us-east-1 中启动新的 EC2 实例。

客户可以尝试创建或调整数据库分支的大小，但由于我们无法启动新的 EC2 实例，这些请求无法完成；它们一直排队等待，直到事件解决。他们现有的 MySQL 或 Postgres 服务器保持可用，而启动新 EC2 实例的请求则处于排队状态。

鉴于美国东海岸即将开始他们的周一，无法启动新的 EC2 实例给我们一些最大的客户带来了风险，这些客户对其 Vitess 集群的 vtgate 组件使用昼夜自动扩缩容。其中一些客户即将进入每周流量高峰，而 vtgate 容量却不到前一周的一半。

PlanetScale 工程师采取了多项干预措施，以尽量减少我们需要在 AWS us-east-1 中启动的 EC2 实例数量：

• 暂时禁止在 AWS us-east-1 中创建新数据库，并将新数据库的默认区域更改为 AWS us-east-2。

• 延迟安排额外备份，并取消等待启动 EC2 实例的待处理备份。（PlanetScale 的标准备份流程会启动一个额外副本，该副本会恢复先前的备份并在进行新备份之前赶上复制，以避免在备份期间降低数据库的容量和容错能力。）

• 建议使用 vtgate 自动扩缩容的 PlanetScale Managed 客户尽可能卸载负载，例如延迟队列处理或暂停 ETL 流程。

我们还采取措施避免终止任何正在运行的 EC2 实例：

• 暂停了我们持续排空并终止超过 30 天的 EC2 实例的流程。

• 停止终止任何变为空闲的 EC2 实例，而是保留它们以供重用。

不过，最重要的干预措施是临时更改我们为配置了自动扩缩容的客户调度 vtgate 进程的方式。我们比平时更紧密地对 vtgate 进程进行装箱打包，使其运行时的 CPU 利用率比通常更接近上限，以便为美国工作日提供充足容量。

除了启动 EC2 实例的问题外，我们还观察到 AWS us-east-1 中出现了部分网络分区。影响似乎大约从 UTC 14:30 开始；然而，我们无法确定到达 PlanetScale 的查询减少是因为网络分区，还是因为上游客户受到影响而发送的查询减少。这些分区在大约 UTC 18:30 到 19:30 之间逐渐恢复。在此期间，一些数据库服务器可以从互联网访问，但无法跨可用区通信以进行查询路由、复制，或两者兼有。一些副本在启动时可以访问容器注册表，但无法从其主 MySQL 或 Postgres 进行复制。一些服务器在解析内部 DNS 名称时遇到问题，另一些服务器在连接到这些 DNS 名称解析到的内部服务时遇到问题。

网络分区导致一些客户相当大比例的查询失败。并非所有数据库分支都受到影响，因为影响在很大程度上取决于使用了哪些可用区，以及流量是否跨可用区传输。在可能的情况下，我们手动发送重新设置父节点请求，将主数据库移动到已知更健康或已知与客户应用程序位于同一位置的可用区。

网络分区恢复后，我们发现少量进程（PlanetScale 的边缘负载均衡器以及 vtgate）由于经历网络分区的方式而无法自行恢复。我们重启了这些进程并恢复了服务。

PlanetScale 的事件指挥官于 UTC 20:32 宣布事件已解决。

反思我们的韧性

PlanetScale 在这次事件中表现良好。控制平面与数据平面的强分离意味着我们控制平面的故障不会影响客户的数据库。冗余和经过实战检验的自动故障转移使主数据库服务器能够移动到网络分区中的多数侧。谨慎的区域流量路由尽可能地避免了网络分区。

但每一次事件都提供了改进的机会。我们正在采取措施，更好地理解并适应我们所依赖的 SaaS 的故障模式，包括 CI/CD、SSO、Web 应用托管和事件通信。

我们正在研究更雄心勃勃的方法，以减少我们对内部和 AWS 服务的运行时依赖。

网络分区是最难推理、测试和容忍的故障模式之一。根据 AWS 的 Well-Architected Framework，使用三个可用区允许我们容忍一个可用区的故障，但前提是另外两个可用区之间的网络连接保持可靠。AWS us-east-1 恰好有六个可用区，我们正在研究 PlanetScale 如何更好地利用它们全部，以对区域故障和它们之间的网络分区更具弹性。

如果您想了解更多关于我们如何为弹性进行工程设计的信息，请阅读 PlanetScale 的《极端容错原则》。

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：PlanetScale Blog

原创地址：https://planetscale.com/blog/aws-us-east-1-incident-2025-10-20