Egy mérnök törölte a GitLab éles adatbázisát. 300 gigabájt.
2017.
2017. január 31., 23:27 UTC: egy GitLab mérnök, egy hosszú éjszaka végén egy meghibásodott replikával küzdve, a PostgreSQL adatkönyvtárat a db1-en távolítja el a db2 helyett. A db1 az elsődleges. A GitLab.com adatbázisának mintegy 300 GB-ja eltűnik egy-két másodperc alatt, és az öt biztonsági mentési és replikációs mechanizmus közül egyik sem működik. Utólagos elemzés: az idővonal a spam rohamtól a rossz hosztnévig, miért tűnt beragadt pg_basebackup-nak, miért hibázott a pg_dump csendesen (9.2 binárisok 9.6 adatbázison, a hibaleveleket a DMARC visszapattintotta), a 6 órás régi előkészítési pillanatképből való 18 órás visszaállítás, élőben közvetítve a YouTube-on, és kit terhel valójában a felelősség. Az elsődlegesnek ítélt válasz: SHIP IT.
Olvassa el az írott kiadást (angolul) ↗
Amit ez a videó tartalmaz
- 2017. január 31.: rm -Rvf az elsődleges adatkönyvtárán; ~300 GB eltávolítva, 4,5 GB maradt
- 5-ből 5 biztonsági mentés sikertelen: üres S3 vödör (pg_dump verzióeltérés), nincs Azure pillanatkép az adatbázison, törölt replika, napi LVM másolat webhooks nélkül
- Február 1., 18:00 UTC: A GitLab.com újra működik egy 6 órával korábbi manuális pillanatképből; élő dokumentum, élő közvetítés, felelősség nélküli utólagos elemzés hibajavító listával
Lefordított átirat
Az eredeti angol narrációból fordítva. A rendelkezésre álló hangot és feliratokat a YouTube vezérli.
0:00 Egy mérnök a GitLab-nál rm -rf parancsot futtat a rossz adatbázis-szerveren, és háromszáz gigabájt GitLab.com eltűnik egy-két másodperc alatt, körülbelül annyi idő alatt, amennyi egy hosztnév elolvasásához szükséges. 2017. január 31., 23:27 UTC. A GitLab tweetel, hogy véletlenül törölte az éles adatokat, nyilvánossá teszi az incidens jegyzeteit az interneten, és élőben közvetíti a helyreállítást a YouTube-on, a platform második legnézettebb élő közvetítéseként. Másnap, írásban: öt biztonsági mentési technika közül,
0:25 egyik sem működik megbízhatóan. Hogyan történik, miért lehetséges, és kit terhel valójában a felelősség. Ez a The Daily Diff, utólagos elemzés. 17:20: egy mérnök pillanatképet készít az éles környezetről egy terheléselosztó teszteléséhez az előkészítő környezetben. 19:00: spam támadja az adatbázist, plusz egy feladat, amely véglegesen töröl egy GitLab alkalmazottat, akit egy troll jelentett visszaélésért. 23:00: a replika annyira lemarad, hogy az elsődleges már elvetette
0:48 a szükséges naplót; az egyetlen megoldás a replika törlése és az elsődleges másolása újra. A pg_basebackup kimenet nélkül lefagy. Valójában csendesen vár az elsődlegesre; senki sem tudja ezt, és a futási kézikönyv sem mondja. A mérnök, aki tizenegykor akart befejezni, úgy dönt, hogy az üres adatkönyvtár a probléma, és eltávolítja. A db1-en. Az elsődlegesen. Egy-két másodperccel később észreveszi; körülbelül háromszáz gigabájtból,
1:11 4,5 maradt. A biztonsági mentések. Egy: pg_dump S3-ba, naponta. A tároló üres. A cron feladat egy olyan alkalmazásszerveren fut, amelyen nincs adatbázis, így a csomag PostgreSQL 9.2 binárisokat választ egy 9.6-os adatbázishoz, hibázik, és e-mailben elküldi a hibát, amelyet DMARC hiány miatt visszapattint. Kettő: Azure lemez pillanatképek, engedélyezve a fájlszerverekhez, nem az adatbázisokhoz.
1:32 Három: a replika, szándékosan törölve egy órával ezelőtt. Négy: a napi pillanatkép, 24 órás, minden webhookot eltávolított a előkészítési szinkronizálás. Öt: az 17:20-as manuális pillanatkép, egy független teszthez. Az nyert. A visszaállítás azt jelenti, hogy az előkészítő lemezt visszamásolják az éles környezetbe az Azure olcsó tárolóján, hatvan megabit másodpercenként: tizennyolc óra. A GitLab.com február 1-jén este hat órakor tér vissza UTC, hat órával régebbi adatokkal.
1:58 git blame: két hosztnév egy karakter eltéréssel, és öt biztonsági mentési rendszer, amiről senki sem állított vissza soha. Nem a mérnök. Az utólagos elemzés, amelyet a vezérigazgató írt alá, anonim marad, pirosra színezi az éles parancssort, és tulajdonost ad az adatok tartósságának, mert eddig nem volt ilyen. Hatósugár: tizennyolc óra leállás, hat órányi adat elveszett, körülbelül ötezer projekt, ötezer komment,
2:18 hétszáz új felhasználó, és ötezer ember néz egy folyamatjelző sávot. A Hacker News 1162 pontot ad az élő dokumentumnak, és egy sort idéz vissza nekik: öt biztonsági mentésből egy sem. Ítélet, utólagos elemzés: SHIP IT, a válaszra. Nyilvánosan kezelik az incidenst, a folyamatot okolják, és közzéteszik a javítási listát hibaszámokkal. Hétfői akció: biztonsági mentés visszaállítása. Ha soha nem állította vissza, akkor nincs is.
2:42 Küldje el nekem az incidenst, amiről még mindig nem beszélhet, a hozzászólásokban, vagy a thedailydiff.dev címen. És ez a mai különbség. Niko vagyok az Axrisi-től. Felelősen egyesítsen.
Források
- 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
