Inženieris izdzēsa GitLab ražošanas datubāzi. 300 gigabaiti.
2017.
2017. gada 31. janvāris, 23:27 UTC: GitLab inženieris, cīnoties ar bojātu repliku garas nakts beigās, noņem PostgreSQL datu direktoriju uz db1, nevis db2. db1 ir primārais. Aptuveni 300 GB no GitLab.com datubāzes pazūd vienā vai divās sekundēs, un no pieciem rezerves un replikācijas mehānismiem neviens nedarbojas. Pēcnāves analīze: laika grafiks no spama pīķa līdz nepareizam resursdatora nosaukumam, kāpēc pg_basebackup izskatījās iestrēdzis, kāpēc pg_dump bija klusi kļūdījies (9.2 binārie faili uz 9.6 datubāzes, kļūdas e-pasta ziņojumi atgriezās DMARC dēļ), 18 stundu atjaunošana no 6 stundas veca posmošanas momentuzņēmuma, kas tika straumēts tiešraidē YouTube, un kurš patiešām ir vainojams. Spriedums par atbildi: SHIP IT.
Lasiet rakstisko izdevumu (angļu valodā) ↗
Ko aptver šis video
- 2017. gada 31. janvāris: rm -Rvf uz primārā datu direktorija; ~300 GB noņemti, atlikuši 4.5 GB
- 5 no 5 dublējumiem neizdodas: tukšs S3 spainis (pg_dump versijas neatbilstība), nav Azure momentuzņēmumu DB, izdzēsta replika, ikdienas LVM kopija bez tīmekļa saišu.
- 1. februāris, 18:00 UTC: GitLab.com atgriezies no 6 stundas veca manuāla momentuzņēmuma; tiešraides dokuments, tiešraides straume, bezvainīga pēcnāves analīze ar labojumu sarakstu
Tulkotais transkripts
Tulkojums no oriģinālā angļu stāstījuma. Pieejamais audio un subtitri tiek kontrolēti no YouTube.
0:00 Inženieris uzņēmumā GitLab palaiž rm -rf uz nepareizā datubāzes servera, un trīssimt gigabaiti GitLab.com pazūd vienā vai divās sekundēs, apmēram tik ilgi, cik nepieciešams, lai izlasītu resursdatora nosaukumu. 2017. gada 31. janvāris, pulksten 23:27 UTC. GitLab tvīto, ka tas nejauši izdzēsa ražošanas datus, atver savas incidentu piezīmes internetam un straumē atjaunošanu YouTube, otra populārākā tiešraide platformā. Nākamajā dienā, rakstiski: no piecām dublējuma metodēm,
0:25 neviena nedarbojas droši. Kā tas notiek, kāpēc tas ir iespējams un kurš patiesībā ir vainīgs. Šis ir The Daily Diff, pēcnāves analīze. 17:20: inženieris izveido ražošanas momentuzņēmumu lai pārbaudītu slodzes balansētāju posmošanā. 19:00: spams pārpludina datubāzi, kā arī darbs, kas neatgriezeniski dzēš GitLab darbinieku, ko ziņojis trolls par ļaunprātīgu izmantošanu. 23:00: replika atpaliek tik tālu, ka primārais jau ir izmetis
0:48 vajadzīgo žurnālu; vienīgais labojums ir izdzēst repliku un nokopēt primāro atkal. pg_basebackup iestrēgst bez izvades. Tas patiesībā klusējot gaida primāro; neviens to nezina, un rokasgrāmatā nav teikts. Inženieris, kurš bija paredzējis pabeigt darbu vienpadsmitos, nolemj, ka tukšais datu direktorijs ir problēma un to noņem. Uz db1. Primārais. Viņš pamana vienu vai divas sekundes vēlāk; no aptuveni trīssimt gigabaitiem,
1:11 paliek 4.5. Dublējumi. Viens: pg_dump uz S3, katru dienu. Grozs ir tukšs. Cron darbs darbojas uz lietojumprogrammas servera bez datubāzes, tāpēc pakotne izvēlas PostgreSQL 9.2 bināros failus 9.6 datubāzei, neizdodas un nosūta e-pastu par kļūdu, kas atgriežas DMARC trūkuma dēļ. Divi: Azure disku momentuzņēmumi, iespējoti failu serveriem, nevis datubāzēm.
1:32 Trīs: replika, apzināti izdzēsta pirms stundas. Četri: ikdienas momentuzņēmums, 24 stundas vecs, katrs tīmekļa saišu izņemts ar posmošanas sinhronizāciju. Pieci: manuālais momentuzņēmums no 17:20, neatkarīgam testam. Tas uzvar. Atjaunošana nozīmē posmošanas diska kopēšanu atpakaļ uz ražošanu, izmantojot Azure lēto glabātuvi ar sešdesmit megabitiem sekundē: astoņpadsmit stundas. GitLab.com atgriežas 1. februārī pulksten sešos vakarā UTC, sešas stundas veci dati.
1:58 git blame: divi resursdatoru nosaukumi, kas atšķiras par vienu rakstzīmi, un piecas dublējuma sistēmas, no kurām neviens nekad nav atjaunots. Ne inženieris. Pēcnāves analīze, ko parakstījis izpilddirektors, saglabā viņa anonimitāti, iekrāso ražošanas uzvedni sarkanu un piešķir datu noturībai īpašnieku, jo līdz šim tāda nebija. Sprādziena rādiuss: astoņpadsmit stundas dīkstāvē, sešas stundas datu zuduma, aptuveni pieci tūkstoši projektu, pieci tūkstoši komentāru,
2:18 septiņi simti jaunu lietotāju un pieci tūkstoši cilvēku, kas vēro progresa joslu. Hacker News piešķir tiešraides dokumentam 1162 punktus un citē vienu rindiņu atpakaļ viņiem: no pieciem dublējumiem – neviena. Spriedums, pēcnāves analīze: SHIP IT, par atbildi. Viņi veic incidentu publiski, vaino procesu un publicē labojumu sarakstu ar problēmu numuriem. Pirmdienas darbība: atjaunot dublējumu. Ja jūs nekad neesat to atjaunojis, jums tāda nav.
2:42 Nosūtiet man incidentu, par kuru jums joprojām nav atļauts runāt, komentāros vai vietnē daily diff dot dev. Un tāda ir šodienas atšķirība. Esmu Niko no Axrisi. Apvienojiet atbildīgi.
Avoti
- 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
