एक शार्पेबल डेटाबेस से डेटा हटाना

एक शार्प सिस्टम से फ़ाइलों को हटाने की प्रक्रिया के अनुकूलन की समस्या को हल करने के बारे में एक लेख। यह फाइलों के साथ साझा करने और काम करने के लिए एक परियोजना के बारे में है। सिस्टम लगभग 8 साल पहले एक स्टार्टअप था, फिर इसे सफलतापूर्वक शूट किया गया और कई बार बेचा गया। परियोजना में 4 डेवलपर्स हैं जो शुरू से ही परियोजना के साथ हैं, जो बहुत मूल्यवान है। दस्तावेज़ीकरण, परंपरागत रूप से, या तो लिखने का समय नहीं था, या यह बहुत प्रासंगिक नहीं है।

आप इसे क्यों पढ़ेंगे और मैंने यह सब क्यों लिखा? मैं एक रेक के बारे में बात करना चाहूंगा जो सावधानी से सिस्टम के अंदर रहता है और हरा देता है ताकि तारे आंखों से बाहर निकल जाएं।

मैं एक साथ काम करने के लिए Hanna_Hlushakova को एक बड़ा धन्यवाद कहना चाहता हूं, परियोजना को अंत तक लाने और लेख तैयार करने में मदद करता हूं । मूल रूप से, आप इसे हल करने के लिए समस्या और एल्गोरिथ्म का वर्णन पाएंगे, जिसका हमने उपयोग किया था, कोड, डेटा संरचनाओं, या अन्य आवश्यक चीजों के उदाहरण नहीं हैं। मुझे नहीं पता कि क्या मेरा अनुभव आपको घर पर रेक से बचने में मदद करेगा, लेकिन मुझे आशा है कि आपको कुछ उपयोगी मिलेगा। शायद यह लेख बहुमूल्य समय का एक अपूरणीय नुकसान होगा।

परियोजना के बारे में

परियोजना गार्टनर स्क्वायर में नेताओं में से एक है, इसके पास संयुक्त राज्य अमेरिका और यूरोप में 300 हजार से अधिक कर्मचारियों और रखरखाव के लिए कई अरब फाइलें हैं।

प्रोजेक्ट में निम्नलिखित तकनीकों का उपयोग किया जाता है: Microsoft, C # .net सर्वर, MS SQL डेटाबेस, 14 सक्रिय सर्वर + 14 डेटा मिररिंग मोड में।

डेटाबेस की मात्रा 4 टीबी तक है, व्यापारिक घंटों में निरंतर लोड प्रति मिनट लगभग 400 हजार अनुरोध है।

डेटाबेस में बहुत सारे व्यावसायिक तर्क हैं:
450 टेबल
1000 संग्रहीत प्रक्रियाओं
SQL कोड की 80,000 लाइनें
परंपरागत रूप से, उनके पास या तो दस्तावेज लिखने का समय नहीं था, या यह प्रासंगिक नहीं है।

कार्य के बारे में

कार्य भंडारण से फ़ाइलों को हटाने को फिर से करना है जो पहले से ही ग्राहकों द्वारा हटा दिए गए हैं, और हटाए गए फ़ाइलों के भंडारण की अवधि समाप्त हो गई है, अगर वे बहाल करना चाहते हैं। वर्तमान संस्करण में, कंपनी की गणना के अनुसार, 1 साल पहले हटा दी गई फ़ाइलों को सर्वरों पर संग्रहीत किया गया था, हालांकि व्यवसाय की शर्तों के अनुसार उन्हें केवल 1 महीने में संग्रहीत किया जाना चाहिए था। चूँकि कुछ फाइलें S3 पर संग्रहीत हैं, कंपनी ने अतिरिक्त डेटा के लिए भुगतान किया था, और जो ग्राहक ऑन-प्रिमाइसेस स्टोरेज का उपयोग कर रहे थे वे सोच रहे थे कि फाइलों को उनकी तुलना में अधिक स्थान क्यों लेना चाहिए।

डेटाबेस क्लाइंट कंपनी के लिए शार्दोवनी।

निष्कासन पहले कैसे काम करता था?

सिस्टम में सभी फ़ाइलों के बारे में जानकारी के साथ एक वैश्विक सर्वर पर, 15 हजार फ़ाइल पहचानकर्ताओं की श्रेणियां बनाई गई थीं।

फिर, शेड्यूल के अनुसार, फ़ाइल पहचानकर्ताओं की एक श्रृंखला के लिए एक सर्वर सर्वेक्षण शुरू किया गया था।
सीमा की सीमाएं प्रत्येक शर्ड को प्रेषित की गईं।

जवाब में शार्द को रेंज से मिली फाइलें मिलीं।

मुख्य सर्वर ने गायब फ़ाइलों को अपने डेटाबेस में हटाने के लिए कतार तालिका में जोड़ा।
फिर, कतार तालिका से, भंडारण से भौतिक फ़ाइल हटाने की सेवा को हटाने के लिए पहचानकर्ताओं का एक समूह प्राप्त हुआ, जिसके बाद यह पुष्टि करता है कि यह फ़ाइलों को हटाने जा रहा है और सभी शार्क के लिए एक चेक शुरू किया गया था कि क्या इन फ़ाइलों का उपयोग किया गया था।
फ़ाइलों की संख्या में वृद्धि के साथ, यह दृष्टिकोण बहुत धीरे-धीरे काम करना शुरू कर दिया, क्योंकि कई बिलियन फाइलें थीं, और रेंज की संख्या में काफी वृद्धि हुई थी। हटाए गए फ़ाइलें अभी भी कुल संख्या की तुलना में 5% से कम रह गई हैं, कई लाखों हटाए गए लोगों को खोजने के लिए अरबों फाइलों के माध्यम से छांटना बहुत ही अक्षम है।

उदाहरण के लिए, आमतौर पर एक उपयोगकर्ता द्वारा किसी फ़ाइल को हटाने के बाद, इसे 1 महीने के लिए संग्रहीत किया जाना चाहिए, अगर इसे बहाल करने की आवश्यकता होती है। इस अवधि के बाद, फ़ाइल को रिपॉजिटरी से प्रोग्राम द्वारा हटा दिया जाना चाहिए। फ़ाइलों की वर्तमान संख्या, श्रेणियों की संख्या और श्रेणियों की गति के साथ, सभी श्रेणियों को पूरी तरह से बायपास करने में सर्वर को 1 वर्ष लगेगा।
यह स्पष्ट है कि जगह को मुक्त नहीं किया गया था, और इससे उपयोगकर्ताओं का असंतोष हुआ, क्योंकि उनके सर्वरों को रिपोर्ट किए जाने की तुलना में कई गुना अधिक फाइलें संग्रहीत की गईं। सेवा कंपनी ने खुद को S3 पर एक अतिरिक्त स्थान के लिए भुगतान किया, जो इसके लिए प्रत्यक्ष नुकसान था।

काम शुरू होने के समय केवल S3 पर, हटाए गए फ़ाइलों के 2 पेटाबाइट संग्रहीत किए गए थे, और यह केवल क्लाउड पर है। इसके अलावा, ऐसे ग्राहक थे जिनकी फाइलें उनके समर्पित सर्वरों पर संग्रहीत थीं, जिसमें एक ही समस्या थी: सर्वर का स्थान उपयोगकर्ताओं द्वारा हटाई गई फ़ाइलों द्वारा कब्जा कर लिया गया था, लेकिन सर्वर से हटाया नहीं गया था।

आपने क्या करने का फैसला किया?

हमने हटाने की घटनाओं पर नज़र रखने का फैसला किया:

• क्लाइंट ने फ़ाइल को हटा दिया और फिर समाप्त हो गया।
• उपयोगकर्ता ने पुनर्प्राप्ति की संभावना के बिना फ़ाइल को तुरंत हटा दिया।

किसी डेटाबेस से फ़ाइल को हटाते समय, हमने एक आशावादी दृष्टिकोण का उपयोग करने और उपयोग के लिए चेक में से एक को हटाने का फैसला किया। हम जानते थे कि 99% फाइलों का उपयोग केवल एक ही हिस्से में किया जाता है। हमने तुरंत फ़ाइल को विलोपन कतार में जोड़ने का निर्णय लिया, और इस फ़ाइल के उपयोग के लिए बाकी हिस्से की जाँच न करें, क्योंकि चेक फिर से तब किया जाएगा जब स्टोर से डिलीट सेवा की पुष्टि करता है।

इसके अलावा, उन्होंने वर्तमान JOB को छोड़ दिया, जो नई फ़ाइलों को रिलीज़ करने से पहले हटाए गए फ़ाइलों को जोड़ने के लिए श्रेणियों द्वारा हटाए गए फ़ाइलों की जाँच करता है।

सब कुछ जो शार्क पर हटा दिया गया था, उसे एक तालिका में एकत्र किया गया है और फिर सभी फाइलों के बारे में जानकारी के साथ एक एकल सर्वर में स्थानांतरित कर दिया गया है।

इस सर्वर पर, इसे डिलीट कतार तालिका में भेजा जाता है।

हटाने से पहले हटाने के लिए तालिका में, यह जाँच की जाती है कि फ़ाइल सभी शार्क पर उपयोग नहीं की गई है। चेक का यह हिस्सा कोड बदलने से पहले यहां था, और उन्होंने इसे नहीं छूने का फैसला किया।

आपको कोड में परिवर्तन करने की आवश्यकता क्या थी?

प्रत्येक शार्क पर, एक तालिका जोड़ी गई थी जिसमें हटाए गए फ़ाइल के पहचानकर्ता को लिखा जाना चाहिए।

हमने डेटाबेस से फ़ाइलों को हटाने के लिए सभी प्रक्रियाओं को पाया, केवल 2 थे। उपयोगकर्ता द्वारा फ़ाइल को हटाने के बाद, फ़ाइल अभी भी कुछ समय के लिए डेटाबेस में निहित है।

डेटाबेस से किसी फ़ाइल को हटाने की प्रक्रिया में, हमने हटाए गए फ़ाइलों के साथ इस स्थानीय तालिका में एक प्रविष्टि जोड़ी।

फ़ाइलों के साथ वैश्विक सर्वर पर, उन्होंने एक JOB बनाया जो शार्क डेटाबेस से फ़ाइलों की एक सूची डाउनलोड करता है। बस एक शल्डेबल डेटाबेस से एक प्रक्रिया को बुलाते हुए, यह अंदर एक DELETE बनाता है और OUTPUT में फ़ाइलों की एक सूची प्रदर्शित करता है। MS SQL सर्वर में खींच - एक दूरस्थ सर्वर से खींचने से एक दूरस्थ सर्वर डालने की तुलना में बहुत तेज है। यह सब ब्लॉकों में किया जाता है।
इन फ़ाइलों को वैश्विक सर्वर पर हटाए गए कतार तालिका में जोड़ा जाता है।
शार्द पहचानकर्ता के साथ एक तालिका कतार तालिका में जोड़ा गया था ताकि यह पता चल सके कि डिलीट इवेंट कहां से आया था।

सभी ने इसका परीक्षण कैसे किया है?

3 वातावरण हैं:

देव विकास का वातावरण है। कोड को जीआईटी की विकसित शाखा से लिया जाता है। IIS पर कोड के एक अलग संस्करण को तैनात करना और ऑर्केस्ट्रेशन के कई संस्करण बनाना संभव है। यह vpn के अंदर क्लाइंट से देव माहौल से जुड़ेगा। हाल तक तक, असुविधा केवल डेटाबेस के साथ थी, क्योंकि डेटाबेस में सभी परिवर्तन सिस्टम के अन्य हिस्सों के काम को तोड़ सकते हैं। फिर ठिकानों को स्थानीय बना दिया गया। पहले से ही चल रहे कोड को डेटाबेस के साथ देव सर्वर पर डाला जा सकता है ताकि हर किसी के काम को बर्बाद न किया जा सके। एक देव वातावरण पर, 12 के बजाय 3 शार्क होते हैं, जो ठेस पर हैं, लेकिन यह आमतौर पर बातचीत का परीक्षण करने के लिए पर्याप्त है।

स्टेजिंग - पर्यावरण कोड के संस्करण के अनुसार ठेस के साथ समान है (लगभग समान है, जैसा कि यह दुर्लभ है, लेकिन प्रशासकों द्वारा सीधे ठेस पर परिवर्तन होते हैं)। मास्टर शाखा से कोड की एक प्रति। कभी-कभी कोड पर कोड के साथ कुछ अंतर डेटाबेस में पकड़े जाते थे, लेकिन सामान्य तौर पर वे समान होते हैं। स्टेजिंग के साथ-साथ युवती पर भी 3 शार्क हैं। मंचन के साथ-साथ देव पर भी कोई भार नहीं है। यहां आप पहले से ही पूरी तरह से एकीकरण परीक्षण चला सकते हैं, क्योंकि कोड ठेस से मेल खाता है। सभी परीक्षणों को पास करना होगा, तैनाती पर जाने से पहले यह एक शर्त है।

परफ़ेक्ट लैब, जहाँ परीक्षण लोड के तहत किए जाते हैं। लोडर का उपयोग जमीटर से किया जाता है, जो कि ठेस की तुलना में 10 गुना कम है, और केवल एक ही शार्प है, जो कभी-कभी असुविधा पैदा करता है। बिक्री डेटा लिया जाता है, फिर बेनामी और इत्र प्रयोगशाला में उपयोग किया जाता है। ठेस के रूप में एक ही विन्यास के सभी सर्वर।

लोड 10 गुना कम है, क्योंकि यह माना जाता है कि यह एक अनुमानित भार है जो 1 शार्द के लिए उत्पादों के लिए आता है। नकारात्मक पक्ष यह है कि बिक्री के विपरीत, वैश्विक आधार को बहुत कम आंका गया है। और, यदि परिवर्तन मुख्य रूप से फ़ाइलों के साथ वैश्विक डेटाबेस की चिंता करते हैं, तो आप केवल परीक्षा परिणामों पर भरोसा कर सकते हैं - ठेस पर यह उस पर काम नहीं कर सकता है। हालाँकि perf लैब आदर्श रूप से प्रोडक्ट्स के साथ लोड से मेल नहीं खाती है, लेकिन लोड के तहत परीक्षण करने की क्षमता पहले से ही प्रोडक्ट्स पर लागू होने से पहले कई त्रुटियों को पकड़ने में मदद करती है।

एक बैकअप सर्वर भी है जहां आप कुछ मामलों को पकड़ने के लिए बिक्री से डेटा देख सकते हैं। सामान्य तौर पर, कंपनी एक लाइसेंस के तहत काम करती है, जो डेवलपर्स को बिक्री डेटा तक पहुंच प्रदान करने से रोकती है, और विकास के लिए प्रशासन और समर्थन टीम (संचालन) का उपयोग करती है, इसलिए आपको डेटाबेस व्यवस्थापकों की मदद लेने की आवश्यकता है। बिक्री डेटा परीक्षण को बहुत आसान बनाता है, क्योंकि कुछ मामले केवल ठग डेटा पर उत्पन्न होते हैं और यह समझने के लिए कि उपयोगकर्ता के लिए सिस्टम कैसे काम करता है, वास्तविक प्रणाली में डेटा का अध्ययन करना बहुत उपयोगी है।

परफ़ेक्ट लैब पर परीक्षणों के दौरान, यह पता चला कि भंडारण से फ़ाइलों को हटाने का भार शब्द से बिल्कुल भी महसूस नहीं किया गया था। लोड टेस्टिंग को लागू करते समय, हमने क्लाइंट सॉफ़्टवेयर से अधिक लोकप्रिय अनुरोधों को चुना, जिनमें से कुछ स्टोरेज को साफ करने में शामिल नहीं थे। चूंकि यह एक डेटाबेस है, यह मैन्युअल रूप से अलग-अलग डेटा पर परिवर्तित प्रक्रियाओं की कॉल के साथ सभी परिवर्तित वस्तुओं के लिए एक सरलीकृत परीक्षण करने के लिए निकला। (उन विकल्पों पर, जिनके बारे में मुझे पता था)।
इसके अलावा, एकीकरण और पूर्ण परीक्षणों में, मुख्य जोर सबसे लोकप्रिय प्रकार के फ़ाइल भंडारण पर रखा गया था।

परफ़ेक्ट लैब की एक अतिरिक्त विशेषता, जो तुरंत पता नहीं लगाई गई थी, वह है ठेस और पर कुछ तालिकाओं में डेटा की मात्रा का बेमेल। इस अर्थ में कि सभी बिक्री JOB पर काम करते हैं, जो डेटा उत्पन्न करते हैं, लेकिन हमेशा कुछ ऐसा नहीं होता है जो तालिका में उत्पन्न डेटा को संसाधित करता है। और, उदाहरण के लिए, perf पर विलोपन के लिए उपर्युक्त सारणी-पंक्ति, ठेस पर की तुलना में बहुत बड़ी है - इत्र पर 20 मिलियन रिकॉर्ड और ठेस पर 200 हजार रिकॉर्ड।

तैनाती की प्रक्रिया

परिनियोजन प्रक्रिया बहुत मानक है। इस कार्य के लिए एप्लिकेशन कोड में कोई परिवर्तन नहीं किए गए थे, सभी परिवर्तन केवल डेटाबेस में हैं। एक DBA को हमेशा डेटाबेस में रोल किया जाता है; यह प्रक्रिया स्वचालित नहीं है। स्क्रिप्ट के 2 संस्करण तैयार किए गए हैं - परिवर्तनों को लागू करने और वापस परिवर्तनों को रोल करने के लिए, और डीबीए के लिए एक निर्देश लिखा गया है। स्क्रिप्ट के 2 संस्करण हमेशा बने होते हैं, और उन्हें आवश्यक रूप से रोलबैक और परिवर्तनों के रोलबैक के लिए परीक्षण किया जाता है। और इन्हीं लिपियों का उपयोग एकीकरण और भार परीक्षण शुरू करने से पहले मचान और परफैक्ट लैब में परिवर्तन लागू करने के लिए किया जाता है।

तैनाती के बाद क्या हुआ?

तैनाती के बाद पहले 5 घंटों में, 1 मिलियन घटनाएं आईं कि क्लाइंट सॉफ़्टवेयर को फ़ाइल डाउनलोड करने की कोशिश करते समय एक त्रुटि मिली। "फ़ाइल दूषित" घटना। इसका मतलब है कि क्लाइंट फ़ाइल डाउनलोड करने की कोशिश कर रहा है, लेकिन फ़ाइल रिपॉजिटरी पर नहीं मिली। आमतौर पर ये घटनाएँ या तो बिल्कुल नहीं होती हैं, या इन्हें प्रति दिन 1 - 2 हजार द्वारा मापा जाता है।

मुझे तुरंत कहना होगा कि 3 और कभी-कभी 5 लोगों की टीम (मेरे सहित) पर असफलता का कारण खोजने में कम से कम 1 सप्ताह का समय लगा।

हमने उन फ़ाइलों की पूरी सूची एकत्र की जिनके लिए "फ़ाइल दूषित" घटना आई थी।

इस तथ्य के बावजूद कि 1 मिलियन से अधिक घटनाएं थीं और वे सभी विभिन्न उपयोगकर्ताओं, विभिन्न कंपनियों से थे, इस सूची में केवल 250 अद्वितीय फाइलें थीं।

बैकअप सर्वर पर DBA डेटाबेस बैकअप की जाँच करने के लिए उठाया गया था जब घटनाओं के आने पर। विश्लेषण में मदद करने वाले सभी प्रकार के लॉग के साथ प्रोजेक्ट बेस में काफी टेबल हैं। डेटाबेस से जानकारी हटाते समय भी, एक लॉग जोड़ा जाता है जिसे हटा दिया गया था और किस घटना से। ठेस पर, ऐसे रिकॉर्ड 1 सप्ताह के लिए संग्रहीत किए जाते हैं, फिर संग्रह सर्वर पर विलय कर दिया जाता है।

और इसलिए लॉग के साथ टेबल हैं जो विश्लेषण करने में बहुत मदद करते हैं कि क्या हुआ:
ग्राहक घटनाओं के साथ एक पूर्ण लॉग प्रत्येक शार्क पर बनाए रखा जाता है

वैश्विक सर्वर पर:

• उपयोगकर्ताओं द्वारा सभी फ़ाइलों को डाउनलोड करने के लिए अनुरोधों का लॉग
• उपयोगकर्ताओं से सिस्टम में अपलोड फ़ाइलें लॉग करें
• FileCorrupt इवेंट लॉग
• संग्रहण से विलोपन को रद्द करने के लिए फ़ाइल लॉग करें
• डेटाबेस से हटाई गई फ़ाइलों का लॉग

इसके अलावा, एप्लिकेशन लॉग के साथ एक ईएलके उपलब्ध था।

हम देव पर्यावरण पर त्रुटि को दोहराने में कामयाब रहे, जिसने धारणा की शुद्धता की पुष्टि की। सबसे पहले, किसी ने भी इस परिकल्पना को गंभीरता से नहीं लिया, क्योंकि यह विश्वास करना बहुत मुश्किल था कि इतने सारे कारक एक ही समय में मेल खाते थे और इतने सारे उपयोगकर्ता इस विशेष समय पर आए।

क्या गलत हुआ?

यह पता चला कि सिस्टम में लगभग 250 (तुलना में, सिस्टम में अरबों फाइलें) सुपर डुपर मेगा लोकप्रिय फाइलें थीं। 250 हाँ!

ये फाइलें अभी भी बहुत पुरानी थीं। जिस समय इन फ़ाइलों को सिस्टम में अपलोड किया गया था, उस समय स्टोरेज के लिए फाइल की बनाने के लिए एक और सिस्टम का उपयोग किया गया था।

यह पता चला कि इस प्रकार की कुंजी के लिए, भौतिक संग्रहण से भौतिक निष्कासन की विधि अन्य फ़ाइलों से भिन्न व्यवहार करती है।

हटाने के साथ वर्ग में, विशेष रूप से पुरानी कुंजी के साथ फ़ाइलों के लिए एक शर्त के साथ एक कोड ब्लॉक है। डिलीट होने के समय, सिस्टम, यह जाँचने से पहले कि फ़ाइल शार्क पर नहीं है, इस पुरानी फ़ाइल को किसी अन्य स्थान पर ले जाता है। खैर, यह काम नहीं किया।

और यह पता चला कि उस समय जब फ़ाइल को स्थानांतरित किया गया था (और मैं याद दिलाऊंगा कि यह बहुत लोकप्रिय है), यदि कोई उपयोगकर्ता उसे नया उपयोगकर्ता अधिकार देने का प्रयास करता है, तो क्लाइंट सॉफ़्टवेयर इस फ़ाइल के लिए संग्रहण में जाता है, लेकिन फ़ाइल सही जगह पर नहीं है। चूंकि इसे स्थानांतरित किया जाता है, इसलिए यह काम नहीं करता है। और क्लाइंट सॉफ़्टवेयर एक संदेश भेजता है कि फ़ाइल टूट गई है। डेटाबेस में, इसे टूटा हुआ के रूप में चिह्नित किया गया है। और सभी जानकारी डेटाबेस (अच्छी तरह से, लगभग सभी) से हटा दी जाती है।

इस बीच, हमारे शारड चेक रूटीन से पता चलता है कि फ़ाइल का उपयोग किया जा रहा है। और एक प्रतिक्रिया भेजता है जिसे आपको इसे वापस करने की आवश्यकता है। लेकिन डेटाबेस से सभी जानकारी पहले ही हटा दी गई है, और इसे वापस करना असंभव है।

मजेदार हुह?

यही है, जब फ़ाइल को हटा दिया गया था, तो उपयोगकर्ता उस समय की अवधि में था जब फ़ाइल को स्थानांतरित किया गया था, शार्प्स ने जांच की थी, और यह इस समय था कि उपयोगकर्ता ने डाउनलोड के लिए अनुरोध भेजा था।

यहां यह है - कार्रवाई में उच्च भार, जब आप मैच के सबसे अविश्वसनीय मैच।



आश्चर्य से उबरने और सब कुछ वापस करने के बाद, हमने सुनिश्चित किया कि उपयोगकर्ताओं की फाइलें जीवित हैं, क्योंकि वे अन्य ग्राहकों के डिस्क से बहाल किए गए थे।

स्वाभाविक रूप से, परीक्षणों में सब कुछ ठीक था, क्योंकि परीक्षण के दौरान नई फ़ाइलों को एक नए कुंजी प्रकार के साथ हटा दिया गया था जिसका उपयोग पिछले 5 वर्षों में किया गया था। ऐसी फ़ाइलों को हटाने के समय के लिए किसी अन्य संग्रहण स्थान पर स्थानांतरित नहीं किया जाता है।

हमारा आशावाद कम हो गया, और हमने सबसे आशावादी रास्ते पर नहीं जाने का फैसला किया।

पूर्वप्रभावी

हमने तय किया कि हमें विभिन्न प्रकार के स्टोरेज के लिए परीक्षणों को जोड़ने की आवश्यकता है
स्टोरेज से हटाए जाने पर कॉल का उपयोग करने वाली संपूर्ण लैब में लोड जोड़ें
प्रसिद्ध दौड़ की स्थिति को बंद करें
निगरानी जोड़ें (हालांकि यह योजनाओं में होगा, लेकिन मूल दायरे में नहीं आया)

निगरानी के बारे में

उन्होंने तुरंत निगरानी करने का फैसला किया, लेकिन फिर वह पृष्ठभूमि में फीका पड़ गया, क्योंकि यह तेजी से तैनात करने के लिए आवश्यक था।

निगरानी के लिए, इस परियोजना में Zabbix, ELK, Grafana, NewRelic, SQL Sentry और AppDynamics के परीक्षण संस्करण का उपयोग किया गया।

इसमें से, pef lab में NewRelic और SQL Sentry था।

हमने पहले से ही सभी सिस्टम मेट्रिक्स को मापा और इसलिए, हम बिजनेस मेट्रिक्स को मापना चाहते थे। मुझे ज़ैबिक्स के माध्यम से इस तरह की निगरानी का आयोजन करने का अनुभव था - हमने ऐसा करने का फैसला किया।

डेटाबेस में एक तालिका बनाने के लिए योजना बहुत सरल है जिसमें JOB द्वारा आवश्यक मैट्रिक्स एकत्र करने के लिए और एक प्रक्रिया जो एकत्रित मैट्रिक्स को Zabbix पर अपलोड करेगी।

मेट्रिक्स:

• वैश्विक आधार पर हटाने के लिए कतार में फ़ाइलों की संख्या
• सर्वर द्वारा कतारबद्ध फ़ाइलों की संख्या
• अनइंस्टालर को भेजी गई फाइलों की संख्या
• हटाई गई फ़ाइलों की संख्या
• FileCorrupt इवेंट्स की संख्या
• प्रत्येक शार्क पर हटाने के लिए फ़ाइलों की संख्या

हटाए जाने के एक नए कार्यान्वयन को लागू करने से पहले निगरानी को लागू किया गया था और अलग-अलग ठिकानों पर तैनात किया गया था।

नया समाधान

सामान्य तौर पर, हमने तय किया कि सोने के बजाय भोजन करना बेहतर था, और एक नई योजना बनाई।

1. उसी शार्द पर जांच करें कि कोई भी अब निश्चित रूप से फ़ाइल का उपयोग नहीं करता है, और केवल अप्रयुक्त फ़ाइलों को सर्वर पर स्थानांतरित कर सकता है;
2. सर्वर में स्थानांतरित करते समय, सभी फ़ाइलों को तालिका में एकत्रित करें और सत्यापित करें कि फ़ाइलों को शार्प क्यूज़ टेबल में रखे जाने से पहले का उपयोग नहीं किया गया है;
3. फ़ाइल का उपयोग करते समय और सिस्टम में इसे खोजने के लिए, सत्यापन की आवश्यकता वाली फ़ाइल के रूप में तालिका में dequeue कतार को चिह्नित करें;
4. केवल उन फ़ाइलों को लौटाएं जिनके लिए कोई खोज नहीं थी;
5. फ़ाइलों को खोजा गया था, शार्क के लिए फिर से जांच;
6. सामान्य तौर पर, फ़ाइल को हटाने वाली प्रक्रिया में चेक को हटा दें, क्योंकि इसे जल्दी से काम करना चाहिए - और उपयोग की गई फ़ाइल इसे सिद्धांत रूप में नहीं पहुंचनी चाहिए;
7. इस प्रक्रिया को ध्यान में रखें कि पीटा फ़ाइल द्वारा सब कुछ हटा दिया जाता है कि यह हटाने की प्रक्रिया में है, और इस पर जानकारी को नहीं हटाएं।

तैनाती के दौरान बिंदु 6 में कई चरणों में चेक को हटाना शामिल था। पहले, उन्होंने चेक छोड़ दिया, फिर एक हफ्ते बाद कंपनी के कर्मचारियों की फाइलों पर लगी चेक को बंद कर दिया गया, 2 हफ्ते बाद उन्होंने चेक को बिल्कुल बंद कर दिया।

आपको कोड में परिवर्तन करने की आवश्यकता क्या थी?

फिर से, सभी परिवर्तन केवल डेटाबेस पर लागू होते हैं।

परिवर्तनों का पैमाना वैश्विक सर्वर पर सबसे बड़ा था:
एक मध्यवर्ती तालिका जोड़ें, जिसमें शार्क से डाउनलोड की गई सभी फ़ाइलों को जोड़ना है।
एक JOB बनाओ जो मध्यवर्ती तालिका की फाइलों की जांच करता है कि उनका उपयोग शार्क पर नहीं किया गया है।

हटाई गई फ़ाइलों की कतार में, उस दिनांक के साथ एक फ़ील्ड जोड़ें जिस फ़ाइल को अंतिम बार एक्सेस किया गया था और एक इंडेक्स जोड़ें।

फ़ाइल तक पहुँच के साथ सभी प्रक्रियाएँ खोजें - यह 5 प्रक्रियाओं को पूरा करती है। उन्हें कतार तालिका में अंतिम उपयोग की तारीख बदलते हुए एक ब्लॉक में जोड़ें। तारीख हर बार बदलती है, भले ही यह भरा गया हो या नहीं।

फ़ाइल जारी करने की प्रक्रिया के लिए विलोपन कार्यक्रम को जोड़ें ताकि यह केवल उपयोग की खाली तारीख वाली फ़ाइलों को प्रदर्शित करे।

एक JOB जोड़ें जो उपयोग और जांच की तारीख के साथ सभी फ़ाइलों को एकत्र करता है (10 मिनट की देरी के साथ, जिसकी आवश्यकता है ताकि क्लाइंट सॉफ़्टवेयर फ़ाइल को शार्क में जोड़ सके, यह आमतौर पर 2 मिनट तक का समय लेता है, लेकिन इसे सुरक्षित रूप से चलाने का निर्णय लिया गया है: सभी शार्क पर फ़ाइल का उपयोग करें। जाँच पूरी होने के बाद, यदि फ़ाइल नहीं मिली है, तो उपयोग की तारीख को रीसेट कर दिया जाता है, अन्यथा फ़ाइल कतार से हटा दी जाती है। यदि सत्यापन प्रक्रिया के दौरान उपयोग की तारीख बदल गई है, तो डेटा नहीं बदलता है क्योंकि यह माना जाता है कि सत्यापन प्रगति पर था, फ़ाइल को शार्क पर अपलोड किया जा सकता था, जिस पर सत्यापन पहले ही पूरा हो चुका था और फ़ाइल के लिए एक नया सत्यापन चक्र आवश्यक था।

शार्क पर:

हटाए गए फ़ाइलों के साथ तालिका से फ़ाइलों को हटाने वाली प्रक्रिया में, यह जांचना आवश्यक था कि फ़ाइल का उपयोग नहीं किया गया था। इस प्रक्रिया ने अपनी सादगी और सुंदरता को बहुत ज्यादा नहीं खो दिया है - DELETE में आउटपुट के साथ उन्होंने बस कुछ नहीं जोड़ा।

हमने एक JOB जोड़ा, जो कि सर्वर पर उपयोग की जाने वाली टेबल फाइलों से धमाके की पृष्ठभूमि में था।

परीक्षण

एकीकरण परीक्षणों में सभी भंडारण विकल्पों के उपयोग पर परिदृश्य जोड़े गए थे।
उन्होंने नई फ़ाइल हटाने की कार्यक्षमता का परीक्षण करने के लिए नए मामले भी लिखे।

परफ़ेक्ट लैब ने वैश्विक सर्वर में लोड जोड़ा। इसके अलावा, हमने स्टोरेज से फाइल्स डिलीट करने के लिए एक लोड जोड़ा है।

तैनाती

डेटाबेस के लिए परिवर्तन के आवेदन और रोलबैक के लिए लिपियों को तैयार किया गया था। DBA ने स्क्रिप्ट्स को रोल किया और यह पता चला कि लोड टेस्टिंग के दौरान उन्होंने फ़ाइलों को हटाने के लिए कतार तालिकाओं पर ताले लगाने पर ध्यान नहीं दिया। नतीजतन, हमने सूचकांक को ठीक नहीं किया, जो सबसे इष्टतम नहीं था।

इस वजह से, नई कोड की तैनाती से पहले सिस्टम में हटाए गए फ़ाइलों के अनुसार, श्रेणियों के आधार पर JOB चेक को अक्षम करना और हटाए गए फ़ाइलों के पहचानकर्ताओं को मैन्युअल रूप से जोड़ना और विश्लेषण करना आवश्यक था।

परिणाम

परिणामस्वरूप, परिनियोजन के परिणामस्वरूप, नई हटाए गए फ़ाइलों को 24 घंटे के भीतर भंडारण से हटा दिया जाता है।
नई प्रणाली के लॉन्च से पहले हटाई गई फ़ाइलें बैकअप पर बनाई गई थीं और ठेस के लिए कतार में जोड़ी गई थीं।

परिणामस्वरूप, 2 पेटाबाइट्स की मात्रा में S3 पर अतिरिक्त डेटा हटा दिया गया था। समर्पित क्लाइंट सर्वर पर फ़ाइलों के साथ भी यही हुआ, और अब सर्वर पर उनका स्थान उनके क्लाइंट पर प्रदर्शित जगह से मेल खाता है।

क्यू टेबल पर घुमावदार इंडेक्स अभी भी ठेस पर रहता है, बैकलॉग में इंडेक्स को बदलने का काम करता है, लेकिन अधिक प्राथमिकता वाले कार्यों के कारण थोड़ा स्थगित हो जाता है।