群里有人说，rm之前要看pwd的，然后有同学接着说，pwd还不够，还要看哪台机器上。 以下为文章正文。 昨天，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小时前的，所以，有如下的数据丢失掉了：
因为GitLab把整个事件的细节公开了出来，所以，也得到了很多外部的帮助，2nd Quadrant的CTO Simon Riggs 在他的blog上也发布文章 Dataloss at GitLab 给了一些非常不错的建议：
看这个样子，估计也有一定的原因是GitLab的同学对PostgreSQL不是很熟悉。 随后，GitLab在其网站上也开了一系列的issues，其issues列表在这里 Write post-mortem (这个列表可能还会在不断更新中)。
|
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
