GitLab事故之技术详叙：抢救后恢复在线，已确定下一步计划

2017年1月31日18:00（UTC时间），GitLab通过推特发文承认300GB生产环境数据因为UNIX SA的误操作，已经被彻底删除（后发文补充说明已经挽回部分数据），引起业界一片哗然。

2017年2月1日 18:14（UTC时间），GitLab.com恢复在线。通过使用一个之前的6小时备份数据库，GitLab申明1月31日下午17:20（UTC时间）至晚上23:25（UTC时间）之间的数据已经被恢复并可以在生产环境使用，包括项目、问题、合并请求、用户、注释等等。

GitLab目前是硅谷一颗冉冉升起的新星，它估值3.29千万美元并且存放着宝贵的用户数据。自2012年上线以来，GitLab已经被超过10万个公司或组织使用，包括IBM、Alibaba.com、UBer、Intel、VMWare等等。

基于 Ruby on Rails 开发的一个开源的版本管理系统，它实现了一个自托管的Git项目仓库，支持通过Web界面进行访问公开的或者私人项目。

GitLab拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，非常易于浏览提交过的版本并提供一个文件历史库。团队成员可以利用内置的简单聊天程序进行交流。此外，GitLab提供了一个代码片段收集功能，可以轻松实现代码复用，便于日后有需要的时候进行查找。

GitLab申明指出其一个数据库出现了异常，导致GitLab.com丢失6个小时的数据库数据（问题、合并请求、用户、注释等等），不过Git / wiki存储库和自托管安装不受影响。

1、 大约6个小时的数据丢失

2、大约丢失5037个项目（其中4613个常规项目，74个fork, 350个import）。由于Git的repository没有任何损失，所以GitLab可以重建数据事故之前已经存在的用户/组的全部项目，但是并不能修复事故中的任何问题。

3、丢失了大约4979（即5000）左右的注释。

4、可能丢失了707个用户，很难准确进行评估（部分源自Kibana记录）

5、受影响的时间点：1月31日17:20之后创建的数据

2017年1月31日18:00（UTC时间）发现垃圾邮件发送者正在通过创建片段方式攻击数据库，目的是让数据库不稳定。工作人员随即开始寻找问题并准备应对方案。

2017年1月31日18:00-21:00（UTC时间），工作人员（team-member-1 ）正在预发布环境安装pgpool和备份工具，为了拿到最新的生产环境数据他创建了一个LVM快照，这个快照会用于预发布环境，他希望可以重用这个快照用于引导其他的副本。这个操作在丢失数据前的6小时完成。

副本启用的过程中发现存在问题，并且需要消耗大量时间（根据估计仅仅是初始化pg_basebackup同步过程就需要耗时20个小时以上）。LVM快照在工作人员可以修复问题之前又不能再其他副本上使用。整个修复过程都被这个问题耽搁下来。

2017年1月31日21:00（UTC时间），开始出现锁定数据库写操作，并引起一些停机情况。进一步进行处理，措施包括锁定垃圾邮件的发送IP、删除一个用户并启用仓库（造成47000个IP使用了相同的账户签名，进而导致数据库高负载）、删除垃圾邮件用户。

2017年1月31日22:00（UTC时间），数据库备份进展出现落后情况，查明造成原因是备份数据库写入操作时出现异常，导致没有跟上备份节奏。

采取处理措施包括：尝试修复db2数据库，这时候备份落后了大概4GB。然后db2集群开始拒绝执行备份作业，db2集群拒绝连接到db1，调整max_wal_senders为db2，重启PostgreSQL数据库，随即PostgreSQL数据库提醒存在很多打开的连接，并拒绝启动服务。管理人员随即调整max_connections参数至8000个，PostgreSQL随即启动。注意，此时db2集群依然拒绝执行备份，处于未知原因的挂起状态。

2017年1月31日23:00（UTC时间），工作人员（team-member-1 ）感觉pg_basebackup拒绝执行的原因是PostgreSQL数据文件夹已经存在，所以决定去移除这个文件夹。执行rm操作之后，该工作人员意识到命令正在db1.cluster.gitlab.com执行，而不是db2.cluster.gitlab.com。

2017年1月31日23:27（UTC时间），工作人员（team-member-1 ）终止了删除操作，300GB的数据仅剩余4.5GB。

GitLab决定下线GitLab.com并将事故通过推特向外公布，并且通过YouTube对外进行了修复过程的直播。

GitLab进一步对遇到的问题进行梳理和逐一解释，包括：

• LVM镜像默认每24小时执行一次。工作人员（team-member-1 ）事故发生6小时之前手动执行了一次。

• 常规备份也是24小时执行一次，但是工作人员（team-member-1 ）无法确定存放于何处。另外一名工作人员（team-member-2）认为这意味着失效，因为产生的文件只有几个字节。

  一名工作人员（Team-member-3）：PostgreSQL9.2的二进制文件开始运行，导致pg_dump失败。由于数据库版本设置为PostgreSQL9.6，最终导致SQL备份不启用。

• Azure上的磁盘镜像只是针对NFS服务器，没有针对数据库服务器。

• 同步过程移除了webhooks。除非我们可以从过去24小时的常规备份中提取这些内容，否则将丢失。

• 复制过程极度脆弱，很易出错，依赖于一系列Shell脚本，而这些脚本的注释很差。

• S3 备份过程没有正常工作。

• 当备份失败时，没有可靠的警报/分页，在dev host上面现在也看到这一点

综上所述，5个备份/复制技术都没有正常工作。无奈之下，我们最终启用6小时之前的备份。

pg_basebackup需要等待主机启动复制过程完毕，这个过程需要10分钟。这个过程会导致我们认为复制过程卡住了。使用strace命令也看不出什么问题原因。

GitLab的官方声明中说明了恢复过程的执行步骤：

1. 2017年2月1日00:36（UTC时间），备份db1.staging.gitlab.com数据。

2. 2017年2月1日00:55（UTC时间），挂载db1.staging.gitlab.com到db1.cluster.gitlab.com。从/var/opt/gitlab/postgresql/data/拷贝数据到生产环境/var/opt/gitlab/postgresql/data/。

3. 2017年2月1日01:05（UTC时间），nfs-share01服务器被征用作为临时备份服务器，放置于/var/opt/gitlab/db-meltdown。

4. 2017年2月1日01:18（UTC时间），包括还存在的生产环境数据，包括pg_xlog，命名为20170131-db-meltodwn-backup.tar.gz。

下面这张图显示了删除和随后恢复事件的时间。

1. 为不同的环境改变Linux终端的格式或者颜色，例如红色代表生产环境，黄色代表测试环境。针对所有用户在shell提示符处显示机器的完整名字，例如db1.staging.gitlab.com，而不是仅仅是“db1”。： https://gitlab.com/gitlab-com/infrastructure/issues/1094

2. 针对postgresql的文件夹拒绝执行rm -rf这样的命令？可以设置命令执行保护或者针对数据库文件夹有对应的备份措施。

3. 为备份增加提醒：检查S3仓库之类的体型。增加图形化界面，显示时间变化后的备份大小，当下降超过10%时发出警报。：https://gitlab.com/gitlab-com/infrastructure/issues/1095

4. 找出为什么PostgreSQL在max_connections被设置为8000之后突然出现问题，这个设置在2016年5月13日就已经完成了。因为这个问题的突然出现导致了其他很多问题。https://gitlab.com/gitlab-com/infrastructure/issues/1096

5. 通过WAL归档增加备份阈值，这个方法对审计失败也许有用。https://gitlab.com/gitlab-com/infrastructure/issues/1097

6. 针对上线产品创建常见问题查找指南手册。

7. 从一个数据中心移动数据到另一个数据中心可以通过AxCopy完成：微软声称这个工具比rsync要快很多。看上去这是Windows上面的问题，但是没有任何Windows专家参与。

GitLab官方申明指出丢失生产环境数据是不可以接受的错误，5天之内GitLab将对外发布错误发生及保护措施失效的原因，并将发布一系列措施避免悲剧再次发生。

GitLab申明最后感谢了共计42位网友的外援，他们通过Twitter和其他渠道上给出的技术建议。

“keturu ta”的评价

我们在日本工作，我们能够理解你们的痛苦和精神上的挫折。我们会一如既往地支持你们。

“Axel Dreyfus”的评价

现在已经很少看到这么开放的工作态度了。祝你们好运，永远支持你们。千万不要针对那个UNIX SA，他已经瘦了20磅（开玩笑）。

“Neer”的评价

这样的事故对于任何人都有可能发生，我鼓励涉及团队不要有挫折感。这篇文章已经开始在社交媒体上流传开来了，让我感到这是一家非常公开和透明的公司。我之前没有听说过这个产品，但是从此以后我会开始使用它。

“Codepotato”的评价

感谢这样的全面解释。问题发生确实让人感觉很丢脸，但是同时也体现了你们对外的开放态度。当务之急我们需要找到办法提升恢复速度。

除了在网络上对事故进行文字说明，GitLab还在YouTube上直播了其数据库修复过程。该过程视频时长8小时，共计有31万人次观看。https://www.youtube.com/watch?v=nc0hPGerSd4

事故处理过程中，GitLab采用了开放的态度，事故发生后第一时间对外公布，并对处理过程进行现场直播，让全世界所有程序员都有机会一起参与恢复过程。GitLab也针对网友提出的关于肇事工作人员如何处理问题进行了官方回应，表态不会因为这次事件解雇事故相关技术人员。

正是由于这样的开放性姿态，网友并没有对事故的发生而进行谩骂、嘲讽，而是一起通过网络对GitLab进行鼓励，对处理事故团队提供积极的技术建议。这样的处理方式可以作为IT公司生产环境经典解决案例被写入教科书。

参考资料

https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub

https://about.gitlab.com/2017/02/01/gitlab-dot-com-database-incident/

https://www.theregister.co.uk/2017/02/01/gitlab_data_loss/