काउचबडी: वन क्रैश हिस्ट्री

मैं इस कहानी को साझा करना चाहता हूं कि हमारी परियोजना एक घंटे और एक घंटे तक चली, और कारणों का पता लगाने का अनुभव।

एक बिंदु पर, हम समझते हैं कि साइट का हिस्सा 15 मिनट की देरी के साथ लोड होता है, और दूसरा हिस्सा केवल काम नहीं करता है, जिससे 50 मिनट की त्रुटि होती है।

चेतावनी! चूंकि लोग स्मार्ट होना पसंद करते हैं, और पढ़ना पसंद नहीं करते हैं, मैं यहां लिखता हूं। पोस्ट का उद्देश्य यह सुझाव देना है कि किसी आपात स्थिति से कैसे बाहर निकलें, बाकी सब सिर्फ गीत हैं, जिस पर किसी न किसी कारण से सभी का ध्यान आकर्षित होता है।

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

इस प्रकार, 7 दिनों के लिए एक घटना को जोड़ने पर, हमें एक दस्तावेज मिलता है जिसमें अवधि क्षेत्र में 7 रिकॉर्ड होते हैं, और 7 रिकॉर्ड प्रदर्शित होते हैं।

विफल

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

गंदा उपयोगकर्ता

एक उपयोगकर्ता एक भुगतान किए गए खाते के साथ दिखाई देता है, और, लाड़ प्यार के लिए, एक घटना जोड़ता है, घटना की अंतिम तिथि 2100 दर्शाता है।
Php-fpm सर्वर पर शक्तिशाली रूप से काम करना शुरू कर देता है, 365 * 100 ईवेंट जोड़ना शुरू करता है। उन्होंने कुछ जोड़ा, लेकिन उपयोगकर्ता ने सफल जोड़ के बारे में एक संदेश का इंतजार नहीं किया, शायद यह तय करते हुए कि कुछ छोटी गाड़ी थी या इंटरनेट बंद हो गया था, और फिर से घटना को जोड़ने पर क्लिक किया, जिससे घटना का समय थोड़ा बदल गया। प्रक्रिया दूसरी बार शुरू हुई। ऐसा नहीं है कि php-fpm ने कोई गंभीर भार दिया है, लेकिन सर्वर पर शीर्ष कमांड में सामान्य से अधिक php-fpm प्रक्रिया थी, जो आपको भ्रमित करती है और आपको गलत दिशा में थोड़ी देर के लिए सोचती है।

नतीजतन, हमारे पास डेटाबेस में 2 दस्तावेज़ हैं जिसमें 365 * 100 प्रत्येक का समय अंतराल है। CouchDB यह नहीं देता है कि देखो अद्यतन करने के लिए शुरू होता है।

सर्वर लॉग में, कुछ इस तरह:
[<0.738.0>] Exit from linked
pid: {<0.742.0>,
{timeout,
{gen_server,call,
[couch_query_servers,
{get_proc,<<"javascript">>}]}}}

Futon में डेटाबेस दर्ज करने की कोशिश करते समय, हम एक os_process_error त्रुटि देखते हैं। Futon की स्थिति अनुभाग में, हम एक गैर-गायब शिलालेख को नोट के साथ देखते हैं कि यह ईवेंट डेटाबेस में है (देखें 1: 1:

एक विचार था कि कुछ छोटी गाड़ी थी या डेटाबेस टूट गया था, लेकिन सर्विस काउचबेड रीस्टार्ट ने मदद नहीं की, साथ ही दूसरे सर्वर पर प्रतिकृति से नवीनतम प्रतिलिपि के साथ सर्वर पर डेटाबेस को बदलने में मदद की।

Googling के बाद, CouchDB मेलिंग सूची संग्रह में एक समाधान पाया गया - डेटाबेस को os_process_timeout = 5000 (5 सेकंड) के अपडेट का सामना करना पड़ा। यह देखने के लिए कि उसके पास आवंटित समय में दस्तावेज़ को संसाधित करने का समय नहीं है। कॉन्फिगरेशन में वैल्यू को 15 सेकंड तक बढ़ाकर, आखिरकार परिवर्तनों के अनुप्रयोग को प्राप्त करना संभव हो गया और साइट सामान्य रूप से काम करने लगी।

इस कारण से निपटा कि साइट ने केवल लोड नहीं किया, 504 त्रुटि दी और डेटाबेस को छाँटकर, स्क्रिप्ट को अंततः बहाल कर दिया गया और इसे फिर से होने से रोकने के लिए उपाय किए गए।

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

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

वर्णित के आधार पर, कुछ निष्कर्ष स्वयं का सुझाव देते हैं

• एक दस्तावेज़ में बहुत सारे डेटा को संग्रहीत न करें, खासकर अगर यह एक सरणी है जो चयन में भाग लेता है। यहां, हालांकि, यह अभी भी एक बहस का सवाल है: क्या बेहतर है - बहुत सारे छोटे दस्तावेज़, या कुछ बड़े, लेकिन हमारे मामले में बहुत बड़े दस्तावेज़ों ने अपना सर्वश्रेष्ठ पक्ष नहीं दिखाया;
• यदि, डेटाबेस में प्रवेश किया है, तो एक os_process_error त्रुटि होती है, और लॉग में शब्द टाइमआउट - कॉन्फ़िगरेशन में os_process_timeout को बढ़ाने का प्रयास करें, यह डेटाबेस को फिर से काम करना शुरू करने और परिणाम वापस करने की अनुमति देगा, जिसमें नवीनतम परिवर्तन संसाधित होंगे;
• एक सुनहरा नियम, जो, अफसोस, हमने किसी विशेष मामले में उपयोग नहीं किया - उपयोगकर्ता द्वारा दर्ज किए गए डेटा की जांच करें, एक चालाक उपयोगकर्ता-गंदे चाल की तरह सोचें।

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

Habré पर PS उपयोगी लेख: CouchDB के साथ काम करने के लिए 16 व्यावहारिक सुझाव ।