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

原创
02/22 06:54
阅读数 448

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

file

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

file

误删库原因

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

file

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

恢复过程

file

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

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

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

复盘

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

file

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

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


💡 更多资讯,请关注 Bytebase 公号:Bytebase

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部