GitLab Dev删除整个生产数据库
作者：互联网
GitLab是最受欢迎的平台之一。但在2017年1月31日，GitLab遇到了一个大问题：他们的一个开发人员意外删除了整个生产数据库，从GitLab.com中删除了六个小时的数据，这是GitLab最大的噩梦之一。
问题：数据太多
问题始于世界标准时间下午6点左右，当时GitLab看到一些坏人在GitLab.com上制作了很多片段（小块代码），使数据库非常繁忙和不稳定。GitLab开始通过他们的IP地址阻止坏人，并删除他们的用户和片段。
世界标准时间晚上9点左右，数据库变得更糟，使写任何东西变得困难，并使网站瘫痪。GitLab看到一个用户将一个项目用作CDN，使47,000个IP使用同一帐户登录。这也让数据库非常繁忙。他们也删除了这个用户。
世界标准时间晚上10点左右，GitLab收到了警报，因为数据库没有将自己复制到另一个数据库，这对备份很重要。发生这种情况是因为有太多的数据需要复制，而另一个数据库无法跟上。GitLab试图通过删除其数据文件夹并再次启动副本来修复另一个数据库。
错误：错误的命令
但副本不起作用，给出了一些错误。GitLab试图更改主数据库上的一些设置，但这使PostgreSQL无法启动，因为打开了太多东西。
世界标准时间晚上11点左右，其中一名开发人员（团队成员-1）认为副本可能不起作用，因为数据文件夹在另一个数据库上（尽管它是空的）。他决定使用rm -rf /var/opt/gitlab/postgresql/data/*删除该文件夹。
但他犯了一个大错误：他在主数据库而不是另一个数据库上运行了命令。这从网站数据库中删除了所有数据，使GitLab.com完全没有数据。
解决方案：使用旧备份
一旦团队成员-1知道他做了什么，他就告诉他的团队成员，并停止了GitLab.com上的一切。他们开始寻找备份来取回数据。
他们发现他们有一些备份方法，但都没有成功：
-
磁盘快照没有打开
-
未找到S3备份
-
DB转储是旧的
-
复制过程被打破了
唯一有效的备份是团队成员-1在问题出现前六小时手工制作的备份。此备份拥有来自GitLab.com的大部分数据，但没有包括人们在这六小时内创建或更改的问题、合并请求、用户、评论、片段等。
GitLab决定使用此备份，使GitLab.com尽快恢复工作。他们还要求用户通过向他们发送他们最近工作的照片或副本来帮助他们找回任何丢失的数据。
备份过程花了很长时间，并且有很多步骤：
-
将备份放在新的数据库服务器上
-
让GitLab使用新的数据库服务器
-
检查和修复备份数据
-
启动GitLab服务并测试是否一切正常
-
与用户交谈，告诉他们发生了什么
在问题开始18个多小时后，GitLab.com终于在UTC2月1日下午6:14左右恢复工作了。
教训：从错误中吸取教训
GitLab非常仔细地研究了这个问题，并写了一篇关于它的博客文章。他们发现了问题发生的原因，以及是什么让情况变得更糟，例如：
-
人为错误：团队成员-1删除了错误的文件夹
-
缺乏验证：没有测试或监视任何备份方法
-
缺乏文档：没有使用备份的明确方法
-
缺乏沟通：没有交谈和合作的好方法
-
睡眠不足：团队成员1晚上工作到很晚，很累
他们还列出了一份要做的事情清单，并更好地阻止此类问题再次发生，例如：
-
打开磁盘快照并检查S3备份
-
改进备份文档和测试方法
-
发出警报并观察备份问题
-
为数据库服务器进行基于角色的访问控制和审计日志记录
-
教授和帮助PostgreSQL副本
-
创造一种无可指责的文化，一种从错误中吸取教训的方法
GitLab的问题对他们和他们的用户来说非常糟糕。这表明他们需要有良好且经过测试的备份，以及清晰和书面的使用方法。
GitLab对这个问题持开放态度，他们与每个人分享了他们发现和学到的东西。他们还向用户道歉，并给了他们一些数据丢失的信息。他们从社区得到了很多反馈和支持，他们喜欢他们的开放和工作。
结论
GitLab搞砸了，丢失了数据，但他们修复了它并从中吸取了教训。GitLab的问题提醒我们所有处理数据和数据库的人要谨慎、聪明和做好准备。我们应该始终检查我们的命令，测试我们的备份，写我们的方式，与团队成员交谈，并从错误中吸取教训。