我在生产中删除了一个数据库，并且没有备份

在每个开发人员的生命中都会有这样一个时刻，他们必须面对这种不可避免的情况。真的，这是我们社区的必经之路。

我写这篇简短的帖子是为了记录导致这起可怕事故的事件，以及从这场惨败中吸取的一些重要教训。

在我们开始之前，先快速概述一下我的基础架构。WorkIndia的基础设施托管在AWS上，其中一些术语指的是AWS服务，但这可能发生在任何在虚拟机上托管数据库的人身上。这个特定的微服务托管在运行API的单个虚拟机、PostgreSQL和使用Docker容器的MongoDB服务器上。

我尝试通过SSH登录机器，但由于CPU负载异常高，我的连接不成功。此时，通常的解决方案是从AWS控制台面板重新启动或停止/启动实例。大错特错了！

我停止该实例，并给它几分钟时间来引导一台新机器并启动码头容器。

突然意识到服务已在Auto Scaling Group(ASG)后面配置。当我停止原来的实例时，ASG找不到健康的机器，它从一个非常旧的启动模板创建了一个新实例。

没关系，至少我有原始实例和所有数据。我只需更改新机器中的数据库主机设置。

一旦我停止了该实例，ASG就确定该实例不健康，并继续永久终止它。这是ASG的默认行为，但是可以使用终止策略将实例从这种命运中拯救出来。

我叫了增援部队，但太晚了。损害已经造成了。PostgreSQL和MongoDB上的所有数据都丢失了。

我信任的同事们立即开始工作，并设计了一个计划，使用来自另一项服务的逻辑重新生成大部分丢失的数据。他们花了不到一天的时间，但谢天谢地，数据或多或少得到了恢复。

基础设施是一项容易出错的业务。作为一名基础设施工程师，我觉得我更多的精力花在创建故障保险上，而不是真正尝试创建一个完全健壮的应用程序。事情会失败的，我们的工作就是优雅地处理失败。

在我们的规模中，将API服务器等无状态应用程序与PostgreSQL和MongoDB等有状态应用程序混合使用是不明智的，这些应用程序有存储需求。无状态应用程序和有状态应用程序遵循不同的规则，因此需要使用截然不同的故障策略。