当事人复盘 GitLab 史上最严重的数据库故障

故事来源于当事人最近发表的回忆录相关节选。

GitLab 官网上还有当年这次事故的纪录，事件发生在 2018 年 2 月 1 日。

误删库原因

GitLab.com 使用的是 PostgreSQL，一主一备两个集群，分别是 db1.cluster.gitlab.com 和 db2.cluster.gitlab.com。当事人 发现 db2 集群无法从 db1 同步数据过来，再尝试了几种方法都不奏效后，就决定尝试重置 db2，也就是清空 db2 的数据目录。只是当事人操作在了主集群 db1 上，当他意识到问题时，300 GB 的数据只剩下 4.5 GB 了。

主库被误删，GitLab.com 只能立马下线了。

恢复过程

GitLab 官方提到有好几道防线，所以最后还是恢复了过来。不过就像一开始当事人回忆里提到的，差一点点就完蛋了。事实上 GitLab 设置的所有防线其实都被击穿了：

• 每天的自动备份不奏效，因为备份所用的 pg_dump 版本和 GitLab 的 PG 版本不一致，所以每次备份只产生了几个 bytes 的数据。
• 在 Azure 上的磁盘备份没有在数据库服务器上启用。
• 到 S3 的备份也是坏的，目录为空。

所幸的是，当事人在操作前的 6 小时，因为知道要处理数据库负载均衡问题，所以做了一个手工备份。所以最后 GitLab.com 花了 24 个小时，把这个手工备份恢复了出来，但是 6 小时的数据是完全没了。

复盘

• 备份恢复需要定期演练。不演练还不如不要备份。这点其实也从侧面体现了云数据库服务商的优势。因为他们能够保障备份的有效性，也提供了 Point-in-time-recovery (PITR) 这样的闪回能力。GitLab 是自己在云主机上搭了数据库服务，手搓一套备份/恢复的方案，结果完全不可用。
• 不要在疲劳时操作数据库。当事人本来已经因为时间很晚，准备休息了。但因为突然出现的同步问题，继续熬夜。

• 尽可能通过工具而不是人肉操作。GitLab 的这个故障应该是当事人直接登上服务器，进行命令行操作的。这里至少有 2 个卡点可以引入工具，一个是登陆服务器，一个是登陆后在服务器上执行命令。如果通过工具操作的话，工具界面会提示正在操作生产库，并且进一步可以设置审批流程。
• 危险操作事前先备份。这个故障可以挽回在于当事人还是一个老手，所以做了事前手工备份，否则后果不堪设想。

前段时间 Linear 误用 TRUNCATE 也造成了其史上最大故障。对生产环境，尤其是数据库上的操作永远要心怀敬畏。操作时应该尽量通过工具自动化。万不得已需要手动挡，始终也要确保有可用备份兜底。

---

💡 更多资讯，请关注 Bytebase 公号：Bytebase