# Ինժեները ջնջել է GitLab-ի արտադրական տվյալների բազան: 300 գիգաբայթ։

Published: 2026-09-10

2017 թվականի հունվարի 31-ին, ժամը 23:27 UTC. GitLab-ի ինժեները, երկար գիշերվա վերջում պայքարելով կոտրված պատճենի հետ, հեռացնում է PostgreSQL-ի տվյալների գրացուցակը db1-ից՝ db2-ի փոխարեն: db1-ը հիմնականն է։ GitLab.com-ի տվյալների բազայի մոտ 300 ԳԲ անհետանում է մեկ-երկու վայրկյանում, և հինգ կրկնօրինակման ու պատճենահանման մեխանիզմներից ոչ մեկը չի աշխատում։ Հետմահու. ժամանակագրությունն աղբի պիկից մինչև սխալ հոսթի անունը, թե ինչու էր pg\_basebackup-ը խրված թվում, թե ինչու էր pg\_dump-ը լուռ ձախողվում (9.2 երկուական ֆայլեր 9.6 տվյալների բազայի վրա, ձախողման էլ. նամակները հետ էին շպրտվում DMARC-ի կողմից), 18-ժամյա վերականգնումը 6-ժամյա հնության փուլային նկարից, որը հեռարձակվում էր YouTube-ով, և թե ով է իրականում մեղավոր։ Արձագանքի վճիռը՝ SHIP IT։

Canonical: https://thedailydiff.dev/hy/video/2026-09-10-gitlab-rm-rf/

## Ինչ է ընդգրկում այս տեսանյութը

- 2017թ. հունվարի 31. rm -Rvf հիմնականի տվյալների գրացուցակում. ~300 ԳԲ հեռացված, 4.5 ԳԲ մնացած։
- 5 կրկնօրինակումներից 5-ը ձախողվում են. դատարկ S3 պահեստ (pg\_dump տարբերակի անհամապատասխանություն), տվյալների բազայում Azure նկարներ չկան, ջնջված պատճեն, ամենօրյա LVM պատճեն առանց վեբ հանգույցների։
- Փետրվարի 1, 18:00 UTC. GitLab.com-ը վերականգնված է 6-ժամյա հնության ձեռքով արված նկարից. կենդանի փաստաթուղթ, կենդանի հոսք, անմեղ հետմահու վերլուծություն շտկումների ցուցակով։

## Թարգմանված արձանագրություն

Թարգմանվել է բնօրինակ անգլերեն պատմությունից։ Հասանելի աուդիո և ենթագրերը վերահսկվում են YouTube-ի կողմից։

0:00 GitLab-ի ինժեներն անսպասելիորեն գործարկում է rm -rf հրամանը սխալ տվյալների բազայի սերվերի վրա, եւ GitLab dot com-ի երեք հարյուր գիգաբայթ տեղեկատվություն անհետանում է մեկ-երկու վայրկյանում, մոտավորապես այնքան ժամանակ է պետք, որքան անհրաժեշտ է հոսթի անուն կարդալու համար։ 2017 թվականի հունվարի 31-ը, ժամը 11:27 երեկոյան, UTC. GitLab-ը թվիթ է անում, որ պատահաբար ջնջել է արտադրական տվյալները, բացում է իր միջադեպի նշումները ինտերնետի համար և հեռարձակում վերականգնումը YouTube-ում, հարթակի երկրորդ ամենադիտված ուղիղ հեռարձակումը։ Հաջորդ օրը, գրավոր. հինգ կրկնօրինակման տեխնիկաներից,

0:25 ոչ մեկը հուսալիորեն չի աշխատում։ Ինչպես է դա տեղի ունենում, ինչու է հնարավոր, և ով է իրականում մեղավոր։ Սա The Daily Diff-ն է, հետմահու վերլուծություն։ Երեկոյան 5:20. ինժեներն արտադրությունից լուսանկար է անում ՝ փորձարկելու բեռնվածության հավասարակշռիչը փուլային միջավայրում։ Ժամը 7 երեկոյան՝ սպամը հարվածում է տվյալների բազային, գումարած մի աշխատանք, որը կոշտ ջնջում է GitLab-ի աշխատակցին մի տրոլի, որին հայտնել էին չարաշահման համար։ Երեկոյան 11-ին. պատճենը այնքան է հետ մնում, որ հիմնականն արդեն մերժել էր

0:48 անհրաժեշտ լոգը. միակ շտկումը պատճենը ջնջելն ու հիմնականը նորից պատճենելն է: pg\_basebackup-ը կախվում է առանց ելքի։ Այն իրականում լուռ սպասում է հիմնականին. ոչ ոք դա չգիտի, և գործարկման ուղեցույցը չի ասում։ Ինժեները, ով մտադիր էր դուրս գալ ժամը տասնմեկին, որոշում է, որ դատարկ տվյալների գրացուցակը խնդիրն է և հեռացնում է այն։ Db1-ի վրա։ Հիմնականը։ Նա նկատում է մեկ-երկու վայրկյան անց. մոտ երեք հարյուր գիգաբայթից,

1:11 4.5-ը մնացել է։ Կրկնօրինակները։ Մեկ. pg\_dump դեպի S3, ամենօրյա։ Պահեստը դատարկ է։ Cron աշխատանքը գործում է հավելվածի սերվերի վրա՝ առանց տվյալների բազայի, ուստի փաթեթը ընտրում է PostgreSQL 9.2 երկուական ֆայլեր 9.6 տվյալների բազայի համար, ձախողվում է և էլեկտրոնային նամակներ է ուղարկում ձախողման մասին, որոնք հետ են մերժվում DMARC-ի բացակայության պատճառով: Երկու. Azure սկավառակի նկարներ, միացված ֆայլային սերվերների համար, ոչ թե տվյալների բազաների։

1:32 Երեք. պատճենը, մեկ ժամ առաջ հատուկ ջնջված։ Չորս. ամենօրյա նկարը, 24 ժամականի հնության, յուրաքանչյուր վեբհանգույց հեռացված է փուլային սինխրոնիզացիայի կողմից։ Հինգ. ձեռքով արված նկարը ժամը 5:20-ից, անկապ թեստի համար։ Այդ մեկը հաղթում է։ Վերականգնումը նշանակում է փուլային սկավառակը կրկնօրինակել արտադրության մեջ Azure-ի էժան պահեստի վրայով՝ վաթսուն մեգաբիթ/վայրկյան արագությամբ. տասնութ ժամ։ GitLab dot com-ը վերադառնում է փետրվարի 1-ին, երեկոյան ժամը վեցին, UTC, վեց ժամով ավելի հին տվյալներով։

1:58 git blame: երկու հոսթի անուններ մեկ նիշով տարբերվում են, և հինգ կրկնօրինակման համակարգեր, որոնցից ոչ ոք երբեք վերականգնում չի կատարել։ Ոչ թե ինժեները։ Գործադիր տնօրենի կողմից ստորագրված հետմահու զեկույցը նրան անանուն է պահում, արտադրական հուշումը կարմրացնում է և տվյալների ամրությանը տեր է տալիս, որովհետև մինչ այդ նա չուներ։ Պայթյունի շառավիղը. տասնութ ժամ անգործություն, վեց ժամ տվյալների կորուստ, մոտ հինգ հազար նախագիծ, հինգ հազար մեկնաբանություն,

2:18 յոթ հարյուր նոր օգտատեր և հինգ հազար մարդ, ովքեր դիտում են առաջընթացի ժապավենը։ Hacker News-ը կենդանի փաստաթղթին տալիս է 1,162 միավոր և մեջբերում է մեկ մի տող նրանց հետ. հինգ կրկնօրինակումից, ոչ մեկը։ Դատավճիռ, հետմահու վերլուծություն՝ SHIP IT, ի պատասխան։ Նրանք հրապարակայնորեն անցկացնում են միջադեպը, մեղադրում են գործընթացին և հրապարակում շտկումների ցուցակը խնդիրների համարների հետ։ Երկուշաբթի օրվա գործողություն. վերականգնել կրկնօրինակը: Եթե երբեք չեք վերականգնել, ուրեմն չունեք։

2:42 Ուղարկեք ինձ այն միջադեպը, որի մասին դեռ թույլ չեն տալիս խոսել, մեկնաբանություններում կամ daily diff dot dev կայքում։ Եվ սա այսօրվա տարբերությունն է։ Ես Նիկոն եմ Axrisi-ից։ Միավորել պատասխանատվությամբ։

## Աղբյուրներ

- [GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)](https://about.gitlab.com/blog/postmortem-of-database-outage-of-january-31/) — about.gitlab.com
- [GitLab, "GitLab.com database incident" (Feb 1, 2017)](https://about.gitlab.com/blog/gitlab-dot-com-database-incident/) — about.gitlab.com
- [@gitlabstatus, "We accidentally deleted production data…"](https://twitter.com/gitlabstatus/status/826591961444384768) — twitter.com
- [@gitlabstatus, emergency maintenance notice](https://twitter.com/gitlabstatus/status/826572933304827904) — twitter.com
- [Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)](https://news.ycombinator.com/item?id=13537052) — news.ycombinator.com
- [Hacker News, the postmortem thread (377 points)](https://news.ycombinator.com/item?id=13619714) — news.ycombinator.com