作为创始人，我不小心删除了生产数据库，还跑路吗？

猛然发现生产数据库被删除

近日，国外用于评分的在线软件提供商 KeepTheScore 猛然发现生产数据库被意外删除，超过 300 块计分牌及相关数据瞬间化为乌有。

好在该公司使用的数据库是云托管数据库，云提供商每天都会进行一次自动备份。经历了 5 分钟的绝望，技术人员进入网站维护模式，而后开始恢复备份。到当天晚间 11:15 左右， 即发生灾难的 30 分钟之后，数据库已经恢复上线，只是过去 7 个小时的数据再也无法找回。

更确切地讲，2020 年 10 月 17 日下午 15：47 至 23：21（CET 时间）之间创建或添加的所有数据均已丢失。

在 KeepTheScore 的回应中写道：“谢天谢地，这场灾难并没有威胁到员工的岗位——创始人不会解雇开发者，因为他们俩是同一个人。另外，这款应用只是个小项目，而不是那种用于支撑电厂运转的大工程。尽管如此，我们还是拥有不少用户，其中还有一些付费用户。我们一直努力让他们满意，但这次事件让他们失望了，真的非常抱歉。”

据公司介绍，删除数据库的函数是在完全严肃清晰的情况下编写而成的。这条函数会删除本地数据库，并从零开始创建所有必要表。就在当天晚上，编程工作仍在继续的同时，该函数接入了生产数据库并将其擦除。

据公司介绍，删除数据库的函数是在完全严肃清晰的情况下编写而成的。这条函数会删除本地数据库，并从零开始创建所有必要表。就在当天晚上，编程工作仍在继续的同时，该函数接入了生产数据库并将其擦除。

下面就是引发这场灾难的代码：

def database_model_create():
"""Only works on localhost to prevent catastrophe"""
database = config.DevelopmentConfig.DB_DATABASE
user = config.DevelopmentConfig.DB_USERNAME
password = config.DevelopmentConfig.DB_PASSWORD
port = config.DevelopmentConfig.DB_PORT
local_db = PostgresqlDatabase(database=database, user=user, password=password, host='localhost', port=port)
local_db.drop_tables([Game, Player, Round, Score, Order])
local_db.create_tables([Game, Player, Round, Score, Order])
print('Initialized the local database.')

KeepTheScore 意识到，单是拥有一条能够删除数据库的函数就已经非常危险。问题是，大家永远无法真正正确而全面地测试安全机制，因为这样的测试要求将矛头指向生产数据库。通过此次事故，KeepTheScore 也意识到拥有一套能够快速恢复的备份有多么重要。

另外，即使是灾难也会有好的一面。但最重要的是，无法百分之百确定类似的问题不会再次发生。计算机系统实在太过复杂，总有一天小毛病会再次惹出大麻烦。

删库事件如何避免和补救？

回顾最近几年的删库事件，我们发现并不在少数，删库原因也各种各样，有误删，有介质损坏，也有人为删除的。

2015 年 5 月，携程员工操作失误，删除了生产服务器上的执行代码，导致官方网站和应用程序大面积瘫痪，无法正常使用；2017 年 1 月，开源代码托管平台 GitLab 系统管理员对数据库进行日常维护时，无意中运行了数据库目录删除命令，导致 300GB 的原始数据只保留了 4.5G，GitLab 被迫下线。

2020 年 2 月 23 日 18 时 56 分，微盟研发中心运维部核心运维人员通过 VPN 登入服务器，并对线上生产环境进行了恶意破坏。这次事件导致了 大约 300 万商家生意停摆，损失巨大。因此，微盟也公布了商家赔付计划，整体准备了 1.5 亿元人民币赔付拨备金，其中微盟公司承担 1 亿元，管理层承担 5000 万元。

针对如何预防删库，如何恢复数据，AI 前线整理了部分技术专家针对此提出的建议：

流程

1. 完善故障演练流程，作为一项共同目标来协作完成，做到忙而不乱

很多公司都会对故障演练存在一些疑虑，因为这会带来一些潜在的隐患，越是不能动，不敢动，在出问题的时候，修复效率越低下，每个人和团队更加关注自己这一部分的工作，显然会忽略一些相关环节，所以能够组织故障演练的流程和规范，把这些梳理和固化下来，在处理问题时才能够做到忙而不乱。

2. 完善故障响应流程，不同等级的问题系统由具体的负责人介入

为什么很多问题的修复进展不可控？一方面是需要团队协作；另一方面是临时去协调和熟悉问题，排查问题的效率是比较低的，可以考虑引入故障的等级分类，及时通知相关团队，把一些问题的处理作为预先处理的环节提前接入。

3. 运维操作需要报备

运维不做无准备的操作，不做加塞操作（比如临时补充一些未经测试的脚本），重要操作，重大操作都需要报备，及时通告，把被动变为主动。

4. 引入审计流程，实现独立的服务审计机制

审计环节是一个相对重要的独立环节，可以引入服务审计机制，可以通过独立的审计服务发现潜在的隐患，及时督正问题。

5. 业务异常预警，需要同步相关链路层

对于业务层的异常，业务预警尤其关键。及时预警并同步到相关链路，可以避免系统雪崩的情况。

2、技术

1. 完善备份恢复体系，使得恢复能够可控，高效。比如，基础备份（全备和增量备份）和热数据恢复 (基于 binlog 的闪回技术)

备份恢复体系的建设是数据库建设的基础，也是衡量服务可用性的最后一根稻草，充分结合全量备份和增量备份，提高恢复效率。

举例来说，下面是一个全量备份和增量备份方案，实现一次全备，永远增量的实现策略，然后在这个基础上实现基于 binlog 的闪回。

2. 集群环境的恢复是系统薄弱环节

系统服务之间互相依赖，这是之前很少有人关注的，所以毫无疑问，这是一块硬骨头，我们需要重点关注。

3. 使用回收站技术，杜绝人为恶意 / 误删除

备份能够解决一些异常情况下的数据恢复，但是效率相对不高，从规范角度来说，如何避免危险操作，转而使用更加优雅可控的处理方式是我们需要思考的问题。

Drop 操作是默认提交的，而且是不可逆的，在数据库操作中都是跑路的代名词，MySQL 层面目前没有相应的 Drop 操作恢复功能，除非通过备份来恢复，但是我们可以考虑将 Drop 操作转换为一种可逆的 DDL 操作。

MySQL 中默认每个表有一个对应的 ibd 文件，其实可以把 Drop 操作转换为一个 rename 操作，即把文件从 testdb 迁移到 testdb_arch 下面；从权限上来说，testdb_arch 是业务不可见的，rename 操作可以平滑的实现这个删除功能，如果在一定时间后确认可以清理，则数据清理对于已有的业务流程是不可见的，如下图所示。

此外，还有两个额外建议，一个是对于大表变更，尽可能考虑低峰时段的在线变更，比如使用 pt-osc 工具或者是维护时段的变更，这里就不再赘述了。

4. 服务权限设置，需指定客户端权限

分业务管理主库和备份库是互联网行业的普遍惯例，很多公司普遍都会授予运维较大的权限，这也是导致很多故障发生的潜在隐患。

在这方面我们可以参考如下的一张设计图（来自张文宇老师），可以在多个环节发力，改进权限问题。

5. 上云是个好方法

技术专家认为数据放在云端的保险系数还是相对较高的，因为云端有足够多的公共资源作为支撑。其中，快照和异地远程复制灾备服务是云端提供的非常好用的功能，建议大家使用。当发生数据删除时，可以使用快照迅速恢复或者回滚到某个历史时刻，然后再通过其他方法补平到最新数据状态；而云端异地远程复制灾备服务也是比较成熟的技术，相比本地实施的容灾，初期投入更加划算。

制度

制度相对来说是比较严格、冷面的，我们可以在技术和流程规范之中寻找一些平衡点来辅助作为制度的基石。比如，密码的安全等级设置，权限管理引入审批制度等，在此就不赘述了。

参考链接：

https://keepthescore.co/blog/posts/deleting_the_production_database/