Een ingenieur heeft de productiedatabase van GitLab verwijderd. 300 gigabyte.
31 januari 2017, 23:27 UTC: een GitLab-ingenieur, vechtend tegen een kapotte replica aan het einde van een lange nacht, verwijdert de PostgreSQL-gegevensmap op db1 in plaats van db2.
31 januari 2017, 23:27 UTC: een GitLab-ingenieur, vechtend tegen een kapotte replica aan het einde van een lange nacht, verwijdert de PostgreSQL-gegevensmap op db1 in plaats van db2. db1 is de primaire. Ongeveer 300 GB van de database van GitLab.com is binnen een seconde of twee verdwenen, en van de vijf back-up- en replicatiemechanismen werkt er geen. Postmortem: de tijdlijn van de spampiek tot de verkeerde hostname, waarom pg_basebackup vast leek te zitten, waarom pg_dump stilzwijgend faalde (9.2 binaries op een 9.6 database, falende e-mails gebounced door DMARC), de 18 uur durende hersteloperatie van een 6 uur oude staging snapshot live gestreamd op YouTube, en wie werkelijk de schuld krijgt. Oordeel over de reactie: SHIP IT.
Lees de geschreven editie (Engels) ↗
Wat deze video behandelt
- 31 jan 2017: rm -Rvf op de gegevensmap van de primaire; ~300 GB verwijderd, 4.5 GB over
- 5 van de 5 back-ups falen: lege S3-bucket (pg_dump versie mismatch), geen Azure-snapshots op de DB, gewiste replica, dagelijkse LVM-kopie zonder webhooks
- 1 feb, 18:00 UTC: GitLab.com terug van een 6 uur oude handmatige snapshot; live document, livestream, blameless postmortem met een fixlijst
Vertaald transcript
Vertaald vanuit de originele Engelse gesproken tekst. Beschikbare audio en ondertiteling worden beheerd door YouTube.
0:00 Een ingenieur bij GitLab voert rm -rf uit op de verkeerde databaseserver, en driehonderd gigabyte van GitLab.com verdwijnt in een seconde of twee, ongeveer hoe lang het duurt om een hostname te lezen. 31 januari 2017, 23:27 UTC. GitLab tweet dat het per ongeluk productiegegevens heeft verwijderd, opent zijn incidentnotities voor het internet en streamt het herstel op YouTube, de nummer twee livestream op het platform. Volgende dag, schriftelijk: van de vijf back-uptechnieken,
0:25 werkt er geen betrouwbaar. Hoe het gebeurt, waarom het mogelijk is, en wie werkelijk de schuld krijgt. Dit is The Daily Diff, postmortem. 17:20 uur: een ingenieur maakt een snapshot van de productie om een load balancer in staging te testen. 19:00 uur: spam hamert op de database, plus een taak die een GitLab-medewerker hard verwijdert die een trol meldde wegens misbruik. 23:00 uur: de replica raakt zo ver achterop dat de primaire de log al heeft weggegooid
0:48 die het nodig heeft; de enige oplossing is om de replica te wissen en de primaire opnieuw te kopiëren. pg_basebackup blijft hangen zonder uitvoer. Het wacht eigenlijk, stilzwijgend, op de primaire; niemand weet dat, en de handleiding vermeldt het niet. De ingenieur, die om elf uur wilde afmelden, besluit dat de lege gegevensmap het probleem is en verwijdert deze. Op db1. De primaire. Hij merkt het een seconde of twee later; van ruwweg driehonderd gigabyte,
1:11 blijft er 4.5 over. De back-ups. Eén: pg_dump naar S3, dagelijks. De bucket is leeg. De cronjob draait op een app-server zonder database, dus het pakket kiest PostgreSQL 9.2 binaries voor een 9.6 database, faalt, en mailt de storing, die wordt gebounced wegens ontbrekende DMARC. Twee: Azure-schijfsnapshots, ingeschakeld voor de bestandsservers, niet de databases.
1:32 Drie: de replica, opzettelijk een uur geleden gewist. Vier: de dagelijkse snapshot, 24 uur oud, elke webhook gestript door de staging-sync. Vijf: de handmatige snapshot van 17:20 uur, voor een niet-gerelateerde test. Die wint. Herstellen betekent de staging-schijf terug kopiëren naar productie via de goedkope opslag van Azure op zestig megabit per seconde: achttien uur. GitLab.com is terug op 1 februari om achttien uur UTC, zes uur gegevens ouder.
1:58 git blame: twee hostnamen die één teken verschillen, en vijf back-upsystemen waarvan niemand ooit heeft hersteld. Niet de ingenieur. De postmortem, ondertekend door de CEO, houdt hem anoniem, kleurt de productietekst rood en geeft databescherming een eigenaar, omdat het tot nu toe geen had. Blast radius: achttien uur downtime, zes uur gegevens verloren, ongeveer vijfduizend projecten, vijfduizend opmerkingen,
2:18 zevenhonderd nieuwe gebruikers, en vijfduizend mensen die een voortgangsbalk bekijken. Hacker News geeft het live document 1.162 punten en citeert één regel terug naar hen: van de vijf back-ups, geen. Oordeel, postmortem: SHIP IT, over de reactie. Ze voeren het incident openbaar uit, wijten het aan het proces en publiceren de fixlijst met issuemmers. Maandag actie: herstel een back-up. Als je het nog nooit hebt hersteld, heb je er geen.
2:42 Stuur me het incident waar je nog steeds niet over mag praten, in de reacties, of op thedailydiff.dev. En dat is de diff voor vandaag. Ik ben Niko van Axrisi. Voeg verantwoordelijk samen.
Bronnen
- GitLab, "Postmortem of database outage of January 31" (Feb 10, 2017)about.gitlab.com
- GitLab, "GitLab.com database incident" (Feb 1, 2017)about.gitlab.com
- @gitlabstatus, "We accidentally deleted production data…"twitter.com
- @gitlabstatus, emergency maintenance noticetwitter.com
- Hacker News, "GitLab Database Incident – Live Report" (1,162 points, 598 comments)news.ycombinator.com
- Hacker News, the postmortem thread (377 points)news.ycombinator.com
