9 月 23 日事件更新

星期四 UTC 时间下午 3:11，Deno 公司提供的几项服务出现了 35 分钟的服务中断。在此期间，托管在 Deno Deploy 的项目和 deno.land 网站没有响应。我们得出结论，这次中断是由于意外的数据库维护事件造成的。这篇文章详细介绍了具体发生了什么，我们如何恢复系统以及我们正在做些什么来防止将来发生这种情况。

所有服务现在都已恢复正常运行。没有数据丢失。我们认真对待此类中断，并真诚地为由此造成的不便道歉。

事件时间线

UTC 时间下午 3:11，托管在 Google Cloud Platform 上的主 Postgres 数据库开始了一次意外的维护事件。

UTC 时间下午 3:13，一个自动警报触发，表明 deno.land/std 的请求失败。

UTC 时间下午 3:32，数据库维护结束，但最终处于未知的故障状态。

UTC 时间下午 3:48，由于早先的故障，数据库服务器自动重启，警报清除。

根本原因

Deno Deploy 拥有一个托管在 Google Cloud Platform 上的主 Postgres 数据库。该数据库用于存储 Deno Deploy 用于运行其服务的各种数据。此数据库以高可用性方式设置，当主数据库发生故障时，可以故障转移到备用副本。

UTC 时间下午 3:11，Google Cloud Platform 在主 Postgres 数据库上启动了一个意外的维护事件。在维护事件期间，故障转移是不可能的。这意味着主数据库不可用于读写，导致访问此数据库的 Deno Deploy 服务发生故障。

维护事件结束后，数据库服务器自动重启，所有使用主数据库的服务都能够恢复。

影响

在 35 分钟的时间窗口内，对 Deno Deploy 项目的请求失败，包括对 deno.land/x 和 deno.land/std 的请求。尝试从 /x 或 /std 下载模块的 Deno 程序遇到了错误。Deno Deploy 管理仪表板 https://dash.deno.com/ 和 Deno Deploy GitHub 集成也无法使用。

接下来会发生什么？

我们正在与 GCP 联系，以确定此维护事件的根本原因以及数据库服务器恢复时间过长的原因。作为一项临时措施，我们将停止计划的数据库维护，直到我们确定永久解决方案以防止此类中断。此外，我们正在研究使我们的服务对主数据库故障更具弹性的解决方案。