GitLab:因“大脑分裂问题” 5台PostgreSQL 3台彻底趴下

新闻 数据库运维 PostgreSQL
数据库复制故障让五台 PostgreSQL 服务器中的三台彻底趴下。在一起典型的故障事件中,GitLab昨天无意中触发了数据库故障切换,因此降低了性能。

数据库复制故障让五台 PostgreSQL 服务器中的三台彻底趴下。

在一起典型的故障事件中,GitLab昨天无意中触发了数据库故障切换,因此降低了性能。

由此引发的“大脑分裂问题”让这家代码收集网站试图靠单单一台数据库服务器postgres-02来服务广大用户,同时竭力恢复另外三台数据库服务器。

这个问题最初出现在美国时间周四凌晨1:30左右,因此而来的重构工作仍在继续之中。

GitLab.com的推文内容如下:

 由于数据库负载,我们目前正在调查GitLab.com上的性能下降和错误。

意外的故障切换被触发后,亚历克斯•汉塞尔卡(Alex Hanselka)写道,虽然服务器群“继续追随真正的主服务器”,但这起事件显然令人痛苦:

“由于postgres-01是出岔子的主服务器,我们关闭了它。我们在调查时发现,postgres-03和postgres-04都试图追随postgres-01。正因为如此,我在写这个问题单(issue)时,我们正在postgres-03上重构复制内容,完成后又在postgres-04上重构复制内容。”

我们在继续调查GitLab上的性能下降问题。想了解详情,请参阅:https://docs.google.com/document

影响性能的还有备份(由于故障切换之前没有完整的pg_basebackup,所以需要备份);由于Sidekiq集群导致庞大的查询,GitLab只好关闭了该集群。

问题刚出来时就是这个情况:近20个小时后,故障工单还没有完结。

一开始,postgres-03的备份以每小时75GB的速度执行,直到23:00(晚上11点)后才完成。仍有其他数据库任务需要完成,但是从安德鲁•纽迪盖特(Andrew Newdigate)的帖子来看,性能开始恢复正常。

自21:30 UTC以来,持续集成/持续交付(CI/CD)队列恢复常态。现在管道以平常的速度来加以处理。

这里还附有时间表:https://docs.google.com/document

至少备份奏效了:2017年2月,备份故障让数据复制错误雪上加霜:“所以换句话说,在部署的5种备份/复制方法中,没有一个可靠地运行或一开始就设置好。”

在一台登台服务器(staging server)上发现了丢失的数据;作了深刻的反复之后,营销副总裁蒂姆•安格拉德(Tim Anglade)告诉IT外媒The Register,他深知GitLab的重要性,这是“对许多人的项目和公司来说很重要的网站。”

不得不说,切实有效的备份至少表明已汲取了一些经验教训。

责任编辑:张燕妮 来源: 云头条
相关推荐

2020-12-24 08:56:18

中台阿里内网

2023-10-21 00:20:16

2019-11-01 09:52:39

中台工具复用

2023-08-29 17:50:01

数字化转型数据中台

2016-05-19 11:22:21

2020-12-21 15:45:53

业务中台数据中台技术中

2013-05-29 15:07:24

2019-05-28 23:00:45

数据中台大数据开源工具

2012-04-26 13:24:05

HTML5

2017-09-21 09:34:57

前端Angular 5

2018-10-10 10:15:57

前端

2018-10-18 10:07:02

戴尔

2009-06-10 16:56:12

可扩展GlassFisJavaEE6

2019-05-23 14:38:54

华为芯片台积电

2016-09-08 10:40:48

易维帮助台

2015-11-19 11:37:18

5G政府研发

2011-12-03 19:16:42

iOS 5

2011-05-16 10:11:27

PlayBookBlackBerryRIM

2015-09-02 09:49:11

日本雅虎OpenStackVM管理

2010-12-21 14:32:43

操作控制台
点赞
收藏

51CTO技术栈公众号