Gitlab.com宕机始末

接上集：Gitlab.com误删数据最近动态：恢复60%

14小时前

数据库恢复60%；

13小时前

gitlab在国外某非著名视频网站直播自己的数据库恢复进展；

13小时前

数据库复制到68%；

12小时前

数据库复制到73%；

11小时前

数据库复制到78%；

10小时前

数据库复制到86%；

10小时前

数据库复制到92%；

2月2日 12:28 AM

数据库复制成功，对数据库做备份快照，以防意外再次发生。

12:45 AM

升级数据库服务器中的GitLab-EE，以使其与复制的数据兼容

12:50 AM

进行数据库恢复，当前Redis缓存将作为部署过程的一部分进行刷新

12:54 AM

数据库的数据已恢复, we're making sure all data we have currently is OK

12:56 AM

我们正在恢复我们的Sentry（错误报告）设置以满足线上环境。

1:24 AM

我们正在按照docs.google.com/document/u/1/d...中所述的数据库恢复检查清单进行逐项检查。

1:24 AM

目前，我们正在确保任何孤立数据得到适当处理

1:36 AM

我们正在尝试恢复丢失的webhooks

1:43 AM

我们的第二个快照包含我们将要恢复的43093个webhook。

1:49 AM

在1月31日17:20 UTC之前创建的Web hook被恢复

1:54 AM

我们现在对GitLab.com进行Smoking Test，并希望很快打开它

1:57 AM

GitLab.com应该可以访问了。

2:01 AM

MR合并状态可能不一致，推送到默认分支应更新它。您可能需要手动关闭MR

5:14 AM

我们将在本周编写/发布数据库post-mortem，更多信息可以在gitlab上的issues中的#1108找到。

9:39 AM

GitLab如此透明的举动，赢来网友点赞，称其透明工作到了一个新的水平！