एक इंजीनियर ने GitLab का प्रोडक्शन डेटाबेस हटा दिया। 300 गीगाबाइट।
31 जनवरी, 2017, 23:27 यूटीसी: एक GitLab इंजीनियर, एक लंबी रात के अंत में एक टूटे हुए रेप्लिका से लड़ते हुए, db2 के बजाय db1 पर PostgreSQL डेटा डायरेक्टरी को हटा देता है।
31 जनवरी, 2017, 23:27 यूटीसी: एक GitLab इंजीनियर, एक लंबी रात के अंत में एक टूटे हुए रेप्लिका से लड़ते हुए, 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 यूटीसी: GitLab.com 6 घंटे पुराने मैनुअल स्नैपशॉट से वापस आया; लाइव डॉक, लाइव स्ट्रीम, फिक्स लिस्ट के साथ दोषरहित पोस्टमॉर्टम।
अनुवादित प्रतिलेख
मूल अंग्रेजी कथन से अनुवादित। उपलब्ध ऑडियो और कैप्शन YouTube द्वारा नियंत्रित होते हैं।
0:00 GitLab का एक इंजीनियर गलत डेटाबेस सर्वर पर rm -rf चलाता है, और GitLab डॉट कॉम के तीन सौ गीगाबाइट एक या दो सेकंड में गायब हो जाते हैं, लगभग उतना ही समय जितना एक होस्टनाम पढ़ने में लगता है। 31 जनवरी, 2017, रात 11:27 बजे। यूटीसी। GitLab ट्वीट करता है कि उसने गलती से प्रोडक्शन डेटा हटा दिया, अपनी घटना के नोट्स इंटरनेट पर खोलता है, और रिकवरी को YouTube पर स्ट्रीम करता है, प्लेटफॉर्म पर नंबर दो लाइव स्ट्रीम। अगले दिन, लिखित रूप में: पांच बैकअप तकनीकों में से,
0:25 कोई भी मज़बूती से काम नहीं कर रहा है। यह कैसे होता है, यह क्यों संभव है, और वास्तव में किसे दोष मिलता है। यह The Daily Diff है, पोस्टमॉर्टम। शाम 5:20 बजे: एक इंजीनियर प्रोडक्शन का स्नैपशॉट लेता है स्टेजिंग में लोड बैलेंसर का परीक्षण करने के लिए। शाम 7 बजे: स्पैम डेटाबेस को हैमर करता है, साथ ही एक जॉब GitLab कर्मचारी को हार्ड-डिलीट कर रहा है, एक ट्रोल ने दुर्व्यवहार की सूचना दी। रात 11 बजे: रेप्लिका इतनी पीछे छूट जाती है कि प्राथमिक ने पहले ही लॉग हटा दिया है
0:48 जो उसे चाहिए; एकमात्र समाधान रेप्लिका को पोंछना और प्राथमिक को कॉपी करना है फिर से। pg_basebackup बिना आउटपुट के लटक जाता है। यह वास्तव में, चुपचाप, प्राथमिक की प्रतीक्षा कर रहा है; कोई नहीं जानता कि, और रनबुक में यह नहीं लिखा है। इंजीनियर, जिसका मतलब ग्यारह बजे लॉग ऑफ करना था, तय करता है कि खाली डेटा डायरेक्टरी समस्या है और इसे हटा देता है। db1 पर। प्राथमिक। वह एक या दो सेकंड बाद देखता है; लगभग तीन सौ गीगाबाइट में से,
1:11 4.5 बचे हैं। बैकअप। एक: pg_dump से S3, दैनिक। बकेट खाली है। क्रोन जॉब बिना डेटाबेस वाले ऐप सर्वर पर चलता है, इसलिए पैकेज चुनता है 9.6 डेटाबेस के लिए PostgreSQL 9.2 बाइनरी, विफल रहता है, और ईमेल करता है विफलता, जो लापता DMARC के लिए बाउंस हो जाती है। दो: Azure डिस्क स्नैपशॉट, फाइल सर्वर के लिए सक्षम, डेटाबेस के लिए नहीं।
1:32 तीन: रेप्लिका, एक घंटे पहले जानबूझकर पोंछ दिया गया। चार: दैनिक स्नैपशॉट, 24 घंटे पुराना, हर वेबहुक को हटा दिया गया स्टेजिंग सिंक। पांच: 5:20 का मैनुअल स्नैपशॉट, एक असंबंधित परीक्षण के लिए। वह जीतता है। बहाल करने का मतलब है स्टेजिंग डिस्क को Azure के सस्ते माध्यम से प्रोडक्शन में वापस कॉपी करना साठ मेगाबिट प्रति सेकंड पर भंडारण: अठारह घंटे। GitLab डॉट कॉम 1 फरवरी को शाम छह बजे वापस आता है। यूटीसी, छह घंटे पुराना डेटा।
1:58 git blame: दो होस्टनाम एक वर्ण अलग, और पांच बैकअप सिस्टम जिससे किसी ने कभी बहाल नहीं किया है। इंजीनियर नहीं। सीईओ द्वारा हस्ताक्षरित पोस्टमॉर्टम, उसे गुमनाम रखता है, प्रोडक्शन प्रॉम्प्ट को लाल रंग देता है, और डेटा स्थायित्व को एक मालिक देता है, क्योंकि अब तक उसका कोई नहीं था। विस्फोट त्रिज्या: अठारह घंटे नीचे, छह घंटे का डेटा गायब, लगभग पांच हजार परियोजनाएं, पांच हजार टिप्पणियां,
2:18 सात सौ नए उपयोगकर्ता, और पांच हजार लोग एक प्रगति पट्टी देख रहे हैं। Hacker News लाइव डॉक को 1,162 अंक देता है और एक उद्धरण देता है लाइन वापस उन पर: पांच बैकअप में से, कोई नहीं। फैसला, पोस्टमॉर्टम: SHIP IT, प्रतिक्रिया पर। वे घटना को सार्वजनिक रूप से चलाते हैं, प्रक्रिया को दोष देते हैं, और फिक्स लिस्ट प्रकाशित करते हैं समस्या संख्या के साथ। सोमवार की कार्रवाई: एक बैकअप बहाल करें। यदि आपने इसे कभी बहाल नहीं किया है, तो आपके पास एक नहीं है।
2:42 मुझे वह घटना भेजें जिसके बारे में आपको अभी भी बात करने की अनुमति नहीं है, टिप्पणियों में, या the 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



