故事来源于当事人最近发表的回忆录相干节选。
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