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

32次阅读

共计 1054 个字符，预计需要花费 3 分钟才能阅读完成。

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

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 个卡点能够引入工具，一个是登陆服务器，一个是登陆后在服务器上执行命令。如果通过工具操作的话，工具界面会提醒正在操作生产库，并且进一步能够设置审批流程。
危险操作事先先备份。这个故障能够挽回在于当事人还是一个新手，所以做了事先手工备份，否则结果不堪设想。