En ingeniør slettet GitLabs produksjonsdatabase. 300 gigabyte.
31.
31. januar 2017, 23:27 UTC: en GitLab-ingeniør, som kjempet mot en ødelagt replika på slutten av en lang natt, fjerner PostgreSQL-datakatalogen på db1 i stedet for db2. db1 er den primære. Omtrent 300 GB av GitLab.coms database er borte på et sekund eller to, og av de fem sikkerhetskopierings- og replikeringsmekanismene fungerer ingen. Postmortem: tidslinjen fra spampiken til feil vertsnavn, hvorfor pg_basebackup virket som den satt fast, hvorfor pg_dump hadde feilet i stillhet (9.2 binærfiler på en 9.6 database, feil-e-poster ble avvist av DMARC), den 18-timers gjenopprettingen fra et 6-timer gammelt staging-øyeblikksbilde streamet direkte på YouTube, og hvem som virkelig får skylden. Dom over responsen: SHIP IT.
Les den skriftlige utgaven (engelsk) ↗
Hva denne videoen dekker
- 31. jan. 2017: rm -Rvf på den primære datakatalogen; ~300 GB fjernet, 4,5 GB igjen
- 5 av 5 sikkerhetskopier feiler: tom S3-bøtte (pg_dump versjonskonflikt), ingen Azure-øyeblikksbilder på DB, slettet replika, daglig LVM-kopi uten webhooks
- 1. feb. 18:00 UTC: GitLab.com tilbake fra et 6-timer gammelt manuelt øyeblikksbilde; live-dokument, live-stream, blameless postmortem med en fikseliste
Oversatt transkripsjon
Oversatt fra den originale engelske fortellingen. Tilgjengelig lyd og undertekster kontrolleres av YouTube.
0:00 En ingeniør hos GitLab kjører rm -rf på feil databaseserver, og tre hundre gigabyte med GitLab dot com forsvinner på et sekund eller to, omtrent hvor lang tid det tar å lese et vertsnavn. 31. januar 2017, kl. 23:27 UTC. GitLab tvitrer at de ved et uhell slettet produksjonsdata, åpner sine hendelsesnotater for internett, og streamer gjenopprettingen på YouTube, den nest mest sette live-streamen på plattformen. Neste dag, skriftlig: av fem sikkerhetskopieringsteknikker,
0:25 ingen fungerer pålitelig. Hvordan det skjer, hvorfor det er mulig, og hvem som faktisk får skylden. Dette er The Daily Diff, postmortem. 17:20: en ingeniør tar et øyeblikksbilde av produksjonen for å teste en lastbalanser i staging. 19:00: spam hamrer databasen, pluss en jobb som hard-sletter en GitLab-ansatt en troll rapportert for misbruk. 23:00: replikaen blir så langt bakpå at den primære allerede har forkastet
0:48 loggen den trenger; den eneste løsningen er å slette replikaen og kopiere den primære igjen. pg_basebackup henger uten utdata. Den venter faktisk, stille, på den primære; ingen vet det, og runbooken sier det ikke. Ingeniøren, som skulle logge av klokken elleve, bestemmer at den tomme datakatalogen er problemet og fjerner den. På db1. Den primære. Han merker det et sekund eller to senere; av omtrent tre hundre gigabyte,
1:11 4,5 gjenstår. Sikkerhetskopiene. Én: pg_dump til S3, daglig. Bøtten er tom. Cron-jobben kjører på en applikasjonsserver uten database, så pakken velger PostgreSQL 9.2 binærfiler for en 9.6 database, feiler, og sender e-post om feilen, som blir avvist på grunn av manglende DMARC. To: Azure disk-øyeblikksbilder, aktivert for filserverne, ikke databasene.
1:32 Tre: replikaen, slettet med vilje for en time siden. Fire: det daglige øyeblikksbildet, 24 timer gammelt, alle webhooks fjernet av staging-synkroniseringen. Fem: det manuelle øyeblikksbildet fra 17:20, for en urelatert test. Den vinner. Gjenoppretting betyr å kopiere staging-disken tilbake til produksjonen over Azures billige lagring med seksti megabit per sekund: atten timer. GitLab dot com er tilbake 1. februar klokken 18:00 UTC, seks timer eldre data.
1:58 git blame: to vertsnavn ett tegn fra hverandre, og fem sikkerhetskopisystemer ingen har noen gang gjenopprettet fra. Ikke ingeniøren. Postmortem-rapporten, signert av administrerende direktør, holder ham anonym, farger produksjonsprompten rød, og gir datavarighet en eier, fordi inntil nå hadde den ingen. Sprengningsradius: atten timer nede, seks timer med data tapt, omtrent fem tusen prosjekter, fem tusen kommentarer,
2:18 syv hundre nye brukere, og fem tusen mennesker som ser på en fremdriftslinje. Hacker News gir live-dokumentet 1 162 poeng og siterer en linje tilbake til dem: av fem sikkerhetskopier, ingen. Dom, postmortem: SHIP IT, om responsen. De kjører hendelsen offentlig, skylder på prosessen, og publiserer fikselisten med saksnumre. Mandagshandling: gjenopprett en sikkerhetskopi. Hvis du aldri har gjenopprettet den, har du ingen.
2:42 Send meg hendelsen du fortsatt ikke får snakke om, i kommentarene, eller på the daily diff dot dev. Og det er dagens diff. Jeg er Niko fra Axrisi. Flett ansvarlig.
Kilder
- 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
