ఒక ఇంజనీర్ గిట్ల్యాబ్ యొక్క ప్రొడక్షన్ డేటాబేస్ను తొలగించాడు. 300 గిగాబైట్లు.
జనవరి 31, 2017, 23:27 UTC: ఒక గిట్ల్యాబ్ ఇంజనీర్, ఒక సుదీర్ఘమైన రాత్రి చివరిలో పాడైపోయిన ప్రతిరూపంతో పోరాడుతూ, db2కి బదులుగా db1లో PostgreSQL డేటా డైరెక్టరీని తొలగించాడు.
జనవరి 31, 2017, 23:27 UTC: ఒక గిట్ల్యాబ్ ఇంజనీర్, ఒక సుదీర్ఘమైన రాత్రి చివరిలో పాడైపోయిన ప్రతిరూపంతో పోరాడుతూ, db2కి బదులుగా db1లో PostgreSQL డేటా డైరెక్టరీని తొలగించాడు. db1 ప్రాథమికమైనది. GitLab.com యొక్క డేటాబేస్లో సుమారు 300 GB ఒకటి లేదా రెండు సెకన్లలో అదృశ్యమయ్యింది, మరియు ఐదు బ్యాకప్ మరియు ప్రతిరూప యంత్రాంగాలలో ఏదీ పనిచేయడం లేదు. పోస్ట్ మార్టం: స్పామ్ స్పైక్ నుండి తప్పు హోస్ట్నేమ్ వరకు కాలక్రమం, pg_basebackup ఎందుకు ఆగిపోయినట్లు కనిపించింది, pg_dump ఎందుకు నిశ్శబ్దంగా విఫలమవుతోంది (9.6 డేటాబేస్లో 9.2 బైనరీస్, DMARC ద్వారా బౌన్స్ అయిన వైఫల్యం ఇ-మెయిల్లు), YouTubeలో ప్రత్యక్ష ప్రసారం చేయబడిన 6 గంటల పాత స్టేజింగ్ స్నాప్షాట్ నుండి 18 గంటల పునరుద్ధరణ, మరియు నిజంగా ఎవరికి నింద వేయాలి. ప్రతిస్పందనపై తీర్పు: SHIP IT.
వ్రాతపూర్వక సంచికను చదవండి (ఇంగ్లీష్) ↗
ఈ వీడియో ఏమి కవర్ చేస్తుంది
- జనవరి 31, 2017: ప్రాథమిక డేటా డైరెక్టరీలో rm -Rvf; ~300 GB తీసివేయబడింది, 4.5 GB మిగిలి ఉంది
- 5 బ్యాకప్లలో 5 విఫలమయ్యాయి: ఖాళీ S3 బకెట్ (pg_dump వెర్షన్ సరిపోలడం లేదు), DBలో Azure స్నాప్షాట్లు లేవు, తుడిచిపెట్టిన ప్రతిరూపం, వెబ్హుక్లు లేని రోజువారీ LVM కాపీ
- ఫిబ్రవరి 1, 18:00 UTC: 6 గంటల పాత మాన్యువల్ స్నాప్షాట్ నుండి GitLab.com తిరిగి వచ్చింది; లైవ్ డాక్యుమెంట్, లైవ్ స్ట్రీమ్, పరిష్కార జాబితాతో నిందారహిత పోస్ట్ మార్టం
అనువదించబడిన ట్రాన్స్క్రిప్ట్
అసలైన ఆంగ్ల కథనం నుండి అనువదించబడింది. అందుబాటులో ఉన్న ఆడియో మరియు క్యాప్షన్లు YouTube ద్వారా నియంత్రించబడతాయి.
0:00 గిట్ల్యాబ్లో ఒక ఇంజనీర్ తప్పు డేటాబేస్ సర్వర్లో rm -rf ని నడుపుతాడు, మరియు గిట్ల్యాబ్ డాట్ కామ్ యొక్క మూడు వందల గిగాబైట్లు ఒకటి లేదా రెండు సెకన్లలో అదృశ్యమవుతాయి, హోస్ట్నేమ్ను చదవడానికి ఎంత సమయం పడుతుందో దాదాపు అంతే. జనవరి 31, 2017, రాత్రి 11:27. UTC. గిట్ల్యాబ్ అనుకోకుండా ప్రొడక్షన్ డేటాను తొలగించిందని ట్వీట్ చేస్తుంది, తన సంఘటన గమనికలను ఇంటర్నెట్కు తెరుస్తుంది మరియు యూట్యూబ్లో పునరుద్ధరణను ప్రసారం చేస్తుంది, ప్లాట్ఫారమ్లో నంబర్ రెండు లైవ్ స్ట్రీమ్. తరువాతి రోజు, వ్రాతపూర్వకంగా: ఐదు బ్యాకప్ పద్ధతులలో,
0:25 ఏదీ విశ్వసనీయంగా పనిచేయడం లేదు. అది ఎలా జరుగుతుంది, అది ఎందుకు సాధ్యం, మరియు నిజంగా ఎవరికి నింద వేయాలి. ఇది The Daily Diff, పోస్ట్ మార్టం. సాయంత్రం 5:20: ఒక ఇంజనీర్ ప్రొడక్షన్ను స్నాప్షాట్ చేస్తాడు స్టేజింగ్లో లోడ్ బ్యాలెన్సర్ను పరీక్షించడానికి. సాయంత్రం 7: స్పామ్ డేటాబేస్ను తాకుతుంది, ప్లస్ ఒక జాబ్ గిట్ల్యాబ్ ఉద్యోగిని కఠినంగా తొలగిస్తుంది దుర్వినియోగానికి ఒక ట్రోల్ నివేదించింది. రాత్రి 11: ప్రతిరూపం చాలా వెనుకబడిపోతుంది, ప్రాథమిక ఇప్పటికే విస్మరించింది
0:48 దానికి అవసరమైన లాగ్; ఒకే పరిష్కారం ప్రతిరూపాన్ని తుడిచివేసి, ప్రాథమికాన్ని కాపీ చేయడం మళ్ళీ. pg_basebackup అవుట్పుట్ లేకుండా ఆగిపోతుంది. అది నిజానికి, నిశ్శబ్దంగా, ప్రాథమిక కోసం వేచి ఉంది; అది ఎవరికీ తెలియదు, మరియు రన్బుక్ చెప్పదు. రాత్రి పదకొండు గంటలకు సైన్ ఆఫ్ చేయాలని అనుకున్న ఇంజనీర్, ఖాళీ డేటా డైరెక్టరీ సమస్య అని నిర్ణయించుకొని దానిని తీసివేస్తాడు. db1లో. ప్రాథమికమైనది. అతను ఒకటి లేదా రెండు సెకన్ల తర్వాత గమనిస్తాడు; దాదాపు మూడు వందల గిగాబైట్లలో,
1:11 4.5 మిగిలి ఉన్నాయి. బ్యాకప్లు. ఒకటి: S3కి pg_dump, రోజువారీ. బకెట్ ఖాళీగా ఉంది. క్రాన్ జాబ్ డేటాబేస్ లేని ఒక యాప్ సర్వర్లో నడుస్తుంది, కాబట్టి ప్యాకేజీ ఎంపిక చేస్తుంది 9.6 డేటాబేస్ కోసం PostgreSQL 9.2 బైనరీస్, విఫలమవుతుంది మరియు ఇమెయిల్లు పంపుతుంది వైఫల్యం, అది DMARC లేకపోవడం వల్ల బౌన్స్ అవుతుంది. రెండు: అజూర్ డిస్క్ స్నాప్షాట్లు, ఫైల్ సర్వర్ల కోసం ప్రారంభించబడ్డాయి, డేటాబేస్ల కోసం కాదు.
1:32 మూడు: ప్రతిరూపం, ఒక గంట క్రితం ఉద్దేశపూర్వకంగా తుడిచివేయబడింది. నాలుగు: రోజువారీ స్నాప్షాట్, 24 గంటల పాతది, ప్రతి వెబ్హుక్ ద్వారా తీసివేయబడింది స్టేజింగ్ సింక్. ఐదు: 5:20 నుండి మాన్యువల్ స్నాప్షాట్, సంబంధం లేని పరీక్ష కోసం. అది గెలుస్తుంది. పునరుద్ధరించడం అంటే స్టేజింగ్ డిస్క్ను అజూర్ యొక్క చౌక ద్వారా ప్రొడక్షన్కు తిరిగి కాపీ చేయడం సెకనుకు అరవై మెగాబిట్ల వద్ద నిల్వ: పద్దెనిమిది గంటలు. గిట్ల్యాబ్ డాట్ కామ్ ఫిబ్రవరి 1న సాయంత్రం ఆరు గంటలకు తిరిగి వచ్చింది. UTC, ఆరు గంటల డేటా పాతది.
1:58 git blame: ఒక అక్షరం దూరంలో ఉన్న రెండు హోస్ట్నేమ్లు మరియు ఐదు బ్యాకప్ సిస్టమ్లు ఎవరూ ఎప్పుడూ పునరుద్ధరించలేదు. ఇంజనీర్ కాదు. CEO సంతకం చేసిన పోస్ట్ మార్టం, అతనిని అనామకంగా ఉంచుతుంది, ప్రొడక్షన్ ప్రాంప్ట్ను ఎరుపు రంగులో చేస్తుంది మరియు డేటా మన్నికకు ఒక యజమానిని ఇస్తుంది, ఎందుకంటే ఇప్పటి వరకు దానికి ఏదీ లేదు. బ్లాస్ట్ వ్యాసార్థం: పద్దెనిమిది గంటలు డౌన్, ఆరు గంటల డేటా పోయింది, దాదాపు ఐదు వేల ప్రాజెక్టులు, ఐదు వేల వ్యాఖ్యలు,
2:18 ఏడు వందల మంది కొత్త వినియోగదారులు మరియు ఐదు వేల మంది పురోగతి పట్టీని చూస్తున్నారు. హ్యాకర్ న్యూస్ లైవ్ డాక్యుమెంట్కు 1,162 పాయింట్లు ఇస్తుంది మరియు ఒక లైన్ను తిరిగి వారికి కోట్ చేస్తుంది: ఐదు బ్యాకప్లలో, ఏదీ లేదు. తీర్పు, పోస్ట్ మార్టం: SHIP IT, ప్రతిస్పందనపై. వారు సంఘటనను బహిరంగంగా నడుపుతారు, ప్రక్రియను నిందిస్తారు మరియు పరిష్కార జాబితాను ప్రచురిస్తారు సమస్య సంఖ్యలతో. సోమవారం చర్య: బ్యాకప్ను పునరుద్ధరించండి. మీరు దానిని ఎప్పుడూ పునరుద్ధరించకపోతే, మీకు ఒకటి లేదు.
2:42 మీరు ఇంకా మాట్లాడటానికి అనుమతించబడని సంఘటనను నాకు పంపండి, వ్యాఖ్యలలో, లేదా daily diff dot dev వద్ద. మరియు ఇది నేటి డిఫ్. నేను Axrisi నుండి నికో. బాధ్యతాయుతంగా విలీనం చేయండి.
మూలాలు
- 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



