# Inžinierius ištrynė „GitLab“ gamybinę duomenų bazę. 300 gigabaitų.

Published: 2026-09-10

2017 m. sausio 31 d., 23:27 UTC: „GitLab“ inžinierius, kovodamas su sugedusiu replikatoriumi ilgos nakties pabaigoje, pašalina „PostgreSQL“ duomenų katalogą iš db1 vietoj db2. db1 yra pirminis. Apie 300 GB „GitLab.com“ duomenų bazės dingo per sekundę ar dvi, o iš penkių atsarginių kopijų ir replikacijos mechanizmų nė vienas neveikia. Po incidento: laiko juosta nuo šlamšto srauto piko iki neteisingo pagrindinio kompiuterio pavadinimo, kodėl pg\_basebackup atrodė užstrigęs, kodėl pg\_dump tyliai nepavyko (9.2 dvejetainiai failai 9.6 duomenų bazėje, DMARC atmetė nesėkmių el. laiškus), 18 valandų atkūrimas iš 6 valandų senumo testavimo momento, transliuojamas tiesiogiai „YouTube“, ir kas iš tikrųjų yra kaltas. Nuosprendis dėl atsako: SHIP IT.

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

## Kas aptariama šiame vaizdo įraše

- 2017 m. sausio 31 d.: rm -Rvf pirminio duomenų kataloge; pašalinta ~300 GB, liko 4,5 GB
- 5 iš 5 atsarginių kopijų nepavyksta: tuščias S3 kibiras (pg\_dump versijų neatitikimas), nėra „Azure“ momentinių kopijų DB, išvalyta replika, kasdienė LVM kopija be webhooks
- Vasario 1 d., 18:00 UTC: „GitLab.com“ vėl veikia iš 6 valandų senumo rankinės momentinės kopijos; gyvas dokumentas, tiesioginė transliacija, be kaltės poincidentinis vertinimas su pataisymų sąrašu

## Išverstas transkriptas

Išversta iš originalo anglų kalbos. Galimas garso ir subtitrų valdymas per YouTube.

0:00 „GitLab“ inžinierius paleidžia rm -rf netinkamame duomenų bazės serveryje, ir trys šimtai gigabaitų „GitLab dot com“ dingsta per sekundę ar dvi, maždaug tiek laiko reikia perskaityti pagrindinio kompiuterio pavadinimą. 2017 m. sausio 31 d., 23:27 val. UTC. „GitLab“ tviteryje praneša, kad netyčia ištrynė gamybinius duomenis, atveria savo incidentų užrašus internetui ir transliuoja atkūrimą „YouTube“, antras pagal populiarumą tiesioginis srautas platformoje. Kitą dieną raštu: iš penkių atsarginių kopijų kūrimo metodų,

0:25 nė vienas neveikia patikimai. Kaip tai nutinka, kodėl tai įmanoma ir kas iš tikrųjų yra kaltas. Tai yra „The Daily Diff“, po incidento. 17:20 val.: inžinierius sukuria gamybinio serverio momentinę kopiją norėdamas patikrinti apkrovos balansaviklį testavimui. 19:00 val.: šlamštas užplūsta duomenų bazę, plius užduotis, kuri sunkiai ištrina „GitLab“ darbuotoją, kurį pranešė trolis dėl piktnaudžiavimo. 23:00 val.: replika taip atsilieka, kad pirminis jau atmetė

0:48 reikalingą žurnalą; vienintelis sprendimas yra išvalyti repliką ir vėl nukopijuoti pirminį serverį. pg\_basebackup pakimba be jokio išvesties. Jis iš tikrųjų laukia, tyliai, pirminio; niekas to nežino, ir žinyne to nėra. Inžinierius, kuris ketino pasirašyti vienuoliktą, nusprendžia, kad tuščias duomenų katalogas yra problema ir jį pašalina. Db1. Pirminis. Jis pastebi po sekundės ar dviejų; iš maždaug trijų šimtų gigabaitų,

1:11 liko 4,5. Atsarginės kopijos. Pirmas: pg\_dump į S3, kasdien. Kibiras tuščias. „Cron“ užduotis vykdoma programų serveryje be duomenų bazės, todėl paketas pasirenka „PostgreSQL 9.2“ dvejetainius failus 9.6 duomenų bazei, nepavyksta ir siunčia el. laiškus apie nesėkmę, kuri atmetama dėl trūkstamo DMARC. Antras: „Azure“ disko momentinės kopijos, įjungtos failų serveriams, o ne duomenų bazėms.

1:32 Trečias: replika, valyta tyčia prieš valandą. Ketvirtas: kasdienė momentinė kopija, 24 valandų senumo, visi webhooks pašalinti testavimo sinchronizavimas. Penktas: rankinė momentinė kopija nuo 17:20, skirta nesusijusiam testui. Tas laimi. Atkūrimas reiškia testavimo disko kopijavimą atgal į gamybą per „Azure“ pigų saugyklą šešiasdešimt megabitų per sekundę: aštuoniolika valandų. „GitLab dot com“ vėl veikia vasario 1 d., 18 val. UTC, šešiomis valandomis senesni duomenys.

1:58 git blame: du pagrindinio kompiuterio pavadinimai, besiskiriantys vienu simboliu, ir penkios atsarginių kopijų sistemos, iš kurių niekas niekada nebuvo atkurta. Ne inžinierius. Poincidentinis vertinimas, pasirašytas generalinio direktoriaus, išlaiko jį anonimišką, gamybinę eilutę nuspalvina raudonai ir suteikia duomenų patvarumo savininką, nes iki šiol jo nebuvo. Sprogimo spindulys: aštuoniolika valandų neveikimo, šešių valandų duomenys prarasti, apie penkis tūkstančius projektų, penkis tūkstančius komentarų,

2:18 septyni šimtai naujų vartotojų ir penki tūkstančiai žmonių, stebinčių progreso juostą. „Hacker News“ suteikia tiesioginiam dokumentui 1 162 taškus ir cituoja vieną eilutę atgal jiems: iš penkių atsarginių kopijų, nė vienos. Nuosprendis, po incidento: SHIP IT, dėl atsako. Jie viešai valdo incidentą, kaltina procesą ir paskelbia pataisymų sąrašą su problemų numeriais. Pirmadienio veiksmas: atkurti atsarginę kopiją. Jei niekada jos neatkūrėte, jos neturite.

2:42 Atsiųskite man incidentą, apie kurį jums vis dar neleidžiama kalbėti, komentaruose arba the daily diff dot dev. Ir tai yra skirtumas šiandien. Aš esu Niko iš Axrisi. Sujunkite atsakingai.

## Šaltiniai

- [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