数据库复制失败导致五分之三的PostgreSQL服务器完全宕机。在典型的故障事件中，GitLab昨天无意中触发了数据库故障转移，从而降低了性能。由此产生的“脑裂问题”导致代码收集站点尝试使用单个数据库服务器postgres-02为大量用户提供服务，同时尝试恢复其他三个数据库服务器。这个问题最早出现在美国时间周四凌晨1:30左右，由此产生的重构仍在进行中。GitLab.com发布了以下推文：我们目前正在调查由于数据库负载导致的GitLab.com性能下降和错误。在触发意外故障转移后，AlexHanselka写道，虽然服务器群“继续跟随真正的主人”，但事件显然令人痛心：“由于postgres-01是发生问题的主服务器，我们将其关闭。我们在调查的时候发现postgres-03和postgres-04都在尝试跟从postgres-01，因此，在我写这个issue的时候，我们运行的是postgres-03，然后在postgres-04上重构copy完毕。”我们正在继续调查GitLab上的性能下降问题。具体可以参考：https://docs.google.com/document还有一个影响性能的备份（因为在fa??ilover之前没有完整的pg_basebackup，所以需要备份）；由于Sidekiq集群带来的巨大查询，GitLab不得不关闭集群。问题刚出来的时候是这样的：快20个小时过去了，故障单还没有关闭。开始时，postgres-03的备份以每小时75GB的速度执行，直到23:00（晚上11点）后才完成。还有其他数据库任务需要完成，但从AndrewNewdigate的帖子来看，性能开始恢复正常。持续集成/持续交付（CI/CD）队列自UTC时间21:30起恢复正常。现在管道以正常速度处理。这是时间表：https://docs.google.com/document至少备份有效：2017年2月，备份失败复合数据复制错误：“换句话说，在5种备份/复制部署方法中，没有一种可靠地工作或者一开始就被安排好了。”在登台服务器上发现丢失的数据；Anglade告诉IT外媒TheRegister，他非常清楚GitLab的重要性，这是“对很多人的项目和公司来说非常重要的网站”。不得不说，有效的备份至少说明了一些经验教训。
