# ’n Ingenieur het GitLab se produksiedatabasis uitgevee. 300 gigagrepe.

Published: 2026-09-10

31 Januarie 2017, 23:27 UTC: ’n GitLab-ingenieur, wat ’n gebroke replika ná ’n lang nag beveg het, verwyder die PostgreSQL-datadirektoraat op db1 in plaas van db2. db1 is die primêre. Ongeveer 300 GB van GitLab.com se databasis is in ’n sekonde of twee weg, en van die vyf rugsteun- en repliseringsmeganismes werk geeneen nie. Postmortem: die tydlyn van die spampiek tot die verkeerde gasheernaam, waarom pg\_basebackup vasgesteek gelyk het, waarom pg\_dump stilweg misluk het (9.2 binêre lêers op ’n 9.6-databasis, mislukking-e-posse teruggestuur deur DMARC), die 18-uur herstel vanaf ’n 6-uur-oue opvoeringskiekie wat regstreeks op YouTube gestroom is, en wie werklik die skuld kry. Uitspraak oor die reaksie: SHIP IT.

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

## Wat hierdie video dek

- 31 Jan 2017: rm -Rvf op die primêre se datadirektoraat; ~300 GB verwyder, 4.5 GB oor
- 5 uit 5 rugsteuns misluk: leë S3-emmer (pg\_dump weergawe-wanpassing), geen Azure-kiekies op die DB, afgeveegde replika, daaglikse LVM-kopie sonder webhooks
- 1 Feb, 18:00 UTC: GitLab.com terug vanaf ’n 6-uur-oue handmatige kiekie; regstreekse dokument, regstreekse stroom, blaamlose postmortem met ’n oplossingslys

## Vertaalde transkripsie

Vertaal uit die oorspronklike Engelse vertelling. Beskikbare klank en onderskrifte word deur YouTube beheer.

0:00 ’n Ingenieur by GitLab voer rm -rf uit op die verkeerde databasisbediener, en driehonderd gigagrepe van GitLab dot com verdwyn in ’n sekonde of twee, omtrent hoe lank dit neem om ’n gasheernaam te lees. 31 Januarie 2017, 11:27 nm. UTC. GitLab twiet dat dit per ongeluk produksiedata uitgevee het, maak sy insidentnotas oop vir die internet, en stroom die herstel op YouTube, die nommer twee regstreekse stroom op die platform. Volgende dag, skriftelik: uit vyf rugsteuntegnieke,

0:25 werk geeneen betroubaar nie. Hoe dit gebeur, waarom dit moontlik is, en wie werklik die skuld kry. Dit is The Daily Diff, postmortem. 5:20 nm.: ’n ingenieur neem ’n kiekie van produksie om ’n lasbalanseerder in opvoering te toets. 7 nm.: strooipos hamer die databasis, plus ’n taak wat ’n GitLab-werknemer hard-uitvee wat ’n trol vir misbruik gerapporteer het. 11 nm.: die replika raak so ver agter dat die primêre reeds weggegooi het

0:48 die log wat dit benodig; die enigste oplossing is om die replika skoon te vee en die primêre weer te kopieer. pg\_basebackup hang sonder uitset. Dit wag eintlik, stilweg, vir die primêre; niemand weet dit nie, en die loopboek sê nie. Die ingenieur, wat bedoel het om om elfuur af te teken, besluit die leë datadirektoraat is die probleem en verwyder dit. Op db1. Die primêre. Hy merk ’n sekonde of twee later op; van ongeveer driehonderd gigagrepe,

1:11 4.5 bly oor. Die rugsteuns. Een: pg\_dump na S3, daagliks. Die emmer is leeg. Die cron-taak loop op ’n toepbediener sonder databasis, so die pakket kies PostgreSQL 9.2 binêre lêers vir ’n 9.6-databasis, misluk, en stuur e-pos die mislukking, wat terugkeer vir ontbrekende DMARC. Twee: Azure-skyfkiekies, geaktiveer vir die lêerbedieners, nie die databasisse nie.

1:32 Drie: die replika, doelbewus ’n uur gelede afgevee. Vier: die daaglikse kiekie, 24 uur oud, elke webhook uitgestrip deur die opvoering-sinchronisasie. Vyf: die handmatige kiekie van 5:20, vir ’n onverwante toets. Dié een wen. Herstel beteken om die opvoering-skyf terug te kopieer na produksie oor Azure se goedkoop berging teen sestig megabit per sekonde: agtien uur. GitLab dot com is terug 1 Februarie om sesuur nm. UTC, ses uur se data ouer.

1:58 git blame: twee gasheername een karakter uitmekaar, en vyf rugsteunstelsels wat niemand het nie ooit van herstel nie. Nie die ingenieur nie. Die postmortem, onderteken deur die HUB, hou hom anoniem, kleur die produksie-aanwysing rooi, en gee data-duursaamheid ’n eienaar, want tot nou toe het dit geen gehad nie. Ontploffingsradius: agtien uur af, ses uur se data weg, ongeveer vyfduisend projekte, vyfduisend opmerkings,

2:18 sewehonderd nuwe gebruikers, en vyfduisend mense wat ’n vorderingsbalk dophou. Hacker News gee die regstreekse dokument 1,162 punte en haal een lyn terug na hulle: uit vyf rugsteuns, geen. Uitspraak, postmortem: ship it, oor die reaksie. Hulle voer die insident in die openbaar uit, blameer die proses, en publiseer die oplossingslys met kwessienommers. Maandag aksie: herstel ’n rugsteun. As jy dit nog nooit herstel het nie, het jy nie een nie.

2:42 Stuur vir my die insident waaroor jy nog steeds nie mag praat nie, in die kommentaar, of by the daily diff dot dev. En dit is die verskil vir vandag. Ek is Niko van Axrisi. Voeg verantwoordelik saam.

## Bronne

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