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