日前，Gitlab.com发生了一个大事，某同学误删了数据库，这个事看似是个低级错误，不过，因为Gitlab把整个过程的细节都全部暴露出来了，所以，可以看到很多东西，而对于类似这样的事情，我自己以前也干过，而在最近的两公司中我也见过(Amazon中见过一次，阿里中见过至少四次)，正好通过这个事来说说一下自己的一些感想和观点吧。我先放个观点：你觉得有备份系统就不会丢数据了吗?
事件回顾
整个事件的回顾Gitlab.com在第一时间就放到了Google Doc上，事后，又发了一篇Blog来说明这个事，在这里，我简单的回顾一下这个事件的过程。
首先，一个叫YP的同学在给gitlab的线上数据库做一些负载均衡的工作，在做这个工作时的时候突发了一个情况，Gitlab被DDoS攻击，数据库的使用飙高，在block完攻击者的IP后，发现有个staging的数据库(db2.staging)已经落后生产库4GB的数据，于是YP同学在Fix这个staging库的同步问题的时候，发现db2.staging有各种问题都和主库无法同步，在这个时候，YP同学已经工作的很晚了，在尝试过多个方法后，发现db2.staging都hang在那里，无法同步，于是他想把db2.staging的数据库删除了，这样全新启动一个新的复制，结果呢，删除数据库的命令错误的敲在了生产环境上(db1.cluster)，结果导致整个生产数据库被误删除。(陈皓注：这个失败基本上就是 “工作时间过长” + “在多数终端窗口中切换中迷失掉了”)
在恢复的过程中，他们发现只有db1.staging的数据库可以用于恢复，而其它的5种备份机制都不可用，第一个是数据库的同步，没有同步webhook，第二个是对硬盘的快照，没有对数据库做，第三个是用pg_dump的备份，发现版本不对(用9.2的版本去dump 9.6的数据)导致没有dump出数据，第四个S3的备份，完全没有备份上，第五个是相关的备份流程是问题百出的，只有几个粗糙的人肉的脚本和糟糕的文档，也就是说，不但是是人肉的，而且还是完全不可执行的。(陈皓注：就算是这些备份机制都work，其实也有问题，因为这些备份大多数基本上都是24小时干一次，所以，要从这些备份恢复也一定是是要丢数据的了，只有第一个数据库同步才会实时一些)
最终，gitlab从db1.staging上把6个小时前的数据copy回来，结果发现速度非常的慢，备份结点只有60Mbits/S，拷了很长时间(陈皓注：为什么不把db1.staging给直接变成生产机?因为那台机器的性能很差)。数据现在的恢复了，不过，因为恢复的数据是6小时前的，所以，有如下的数据丢失掉了：
粗略估计，有4613 的项目， 74 forks, 和 350 imports 丢失了;但是，因为Git仓库还在，所以，可以从Git仓库反向推导数据库中的数据，但是，项目中的issues等就完全丢失了。 大约有±4979 提交记录丢失了(陈皓注：估计也可以用git仓库中反向恢复)。 可能有 707 用户丢失了，这个数据来自Kibana的日志。 在1月31日17:20 后的Webhooks 丢失了。
因为Gitlab把整个事件的细节公开了出来，所以，也得到了很多外部的帮助，2nd Quadrant的CTO – Simon Riggs 在他的blog上也发布文章 Dataloss at Gitlab 给了一些非常不错的建议：
关于PostgreSQL 9.6的数据同步hang住的问题，可能有一些Bug，正在fix中。 PostgreSQL有4GB的同步滞后是正常的，这不是什么问题。 正常的停止从结点，会让主结点自动释放WALSender的链接数，所以，不应该重新配置主结点的 max_wal_senders 参数。但是，停止从结点时，主结点的复数连接数不会很快的被释放，而新启动的从结点又会消耗更多的链接数。他认为，Gitlab配置的32个链接数太高了，通常来说，2到4个就足够了。 另外，之前gitlab配置的max_connections=8000太高了，现在降到2000个是合理的。 pg_basebackup 会先在主结点上建一个checkpoint，然后再开始同步，这个过程大约需要4分钟。 手动的删除数据库目录是非常危险的操作，这个事应该交给程序来做。推荐使用刚release 的 repmgr 恢复备份也是非常重要的，所以，也应该用相应的程序来做。推荐使用 barman (其支持S3) 测试备份和恢复是一个很重要的过程。
看这个样子，估计也有一定的原因是——Gitlab的同学对PostgreSQL不是很熟悉。
随后，Gitlab在其网站上也开了一系列的issues，其issues列表在这里 Write post-mortem (这个列表可能还会在不断更新中)
