PostgreSQL के साथ काम करते समय शीर्ष विकास की गलतियाँ

HighLoad ++ लंबे समय से आसपास है , और हम नियमित रूप से PostgreSQL के साथ काम करने के बारे में बात करते हैं। लेकिन डेवलपर्स को अभी भी महीने से महीने तक, वर्ष से वर्ष तक समान समस्याएं हैं। जब राज्य में डीबीए के बिना छोटी कंपनियों में डेटाबेस के साथ काम करने में त्रुटियां होती हैं, तो यह आश्चर्य की बात नहीं है। बड़ी कंपनियों को भी डेटाबेस की आवश्यकता होती है, और यहां तक ​​कि डीबग की गई प्रक्रियाओं के साथ, त्रुटियां अभी भी होती हैं और डेटाबेस गिर जाते हैं। इससे कोई फर्क नहीं पड़ता कि कंपनी किस आकार की है - त्रुटियां अभी भी होती हैं, डेटाबेस समय-समय पर क्रैश, क्रैश।



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


स्पीकर के बारे में: एलेक्सी लेसोवस्की ने लिनक्स सिस्टम प्रशासक के रूप में शुरुआत की। वर्चुअलाइजेशन और मॉनिटरिंग सिस्टम के कार्यों से धीरे-धीरे PostgreSQL में आया। अब डेटा एग्रेट में PostgreSQL DBA, एक परामर्श कंपनी है जो कई अलग-अलग परियोजनाओं के साथ काम करती है और आवर्ती समस्याओं के कई उदाहरण देखती है। यह HighLoad ++ 2018 की रिपोर्ट की प्रस्तुति की एक कड़ी है।

समस्याएं कहां से आती हैं

वार्म अप करने के लिए, त्रुटियों के बारे में कुछ कहानियाँ।

इतिहास 1. सुविधाएँ

समस्याओं में से एक वह है जो पोस्टग्रेएसक्यूएल के साथ काम करते समय कंपनी का उपयोग करती है। यह सब सरल शुरू होता है: PostgreSQL, डेटासेट, JOIN के साथ सरल प्रश्न। हम डेटा लेते हैं, सेलेक्ट करते हैं - सब कुछ सरल है।

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

प्रत्येक कीवर्ड प्रकट होने में त्रुटि का कारण है।

इतिहास 2. डेटा संग्रहण

जिस तरह से हम डेटा स्टोर करते हैं वह भी त्रुटियों का एक स्रोत है।

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



और यह सिर्फ हिमशैल की नोक है - कहीं ओर एक और 400 तालिकाओं, विभाजन हो सकते हैं, जिसमें से डेटा भी कभी-कभी पढ़ा जाता है।

इतिहास 3. जीवन चक्र

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

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



दूसरी ओर , एडमिन। वे नंगे-धातु पर नए अमेज़िंग उदाहरण उठाते हैं और स्वचालन के साथ व्यस्त हैं: वे लेआउट को अच्छी तरह से काम करने के लिए तैनाती की स्थापना करते हैं, और कॉन्फ़िगर करते हैं ताकि सेवाएं एक-दूसरे के साथ अच्छी तरह से बातचीत करें।



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

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

योजना और निगरानी

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

लेकिन अधिक उपयोगकर्ता हैं, ट्रैफ़िक आता है: नया डेटा प्रकट होता है, डेटाबेस बढ़ते हैं और पुराने प्रश्न काम करना बंद कर देते हैं। अनुक्रमणिका को पूरा करना, प्रश्नों को फिर से लिखना और अनुकूलित करना आवश्यक है। प्रदर्शन के मुद्दे हैं। यह सब सुबह 4 बजे अलर्ट की ओर जाता है, प्रवेश और प्रबंधन के असंतोष के लिए तनाव।

क्या गलत है?

मेरे अनुभव में, ज्यादातर अक्सर पर्याप्त डिस्क नहीं होते हैं।

पहला उदाहरण । हम डिस्क उपयोग की निगरानी के लिए अनुसूची खोलते हैं, और हम देखते हैं कि डिस्क पर खाली स्थान बाहर चल रहा है ।



हम देखते हैं कि कितना स्थान और क्या खाया जाता है - यह पता चला है कि एक pg_xlog निर्देशिका है:

$ du -csh -t 100M /pgdb/9.6/main/* 15G /pgdb/9.6/main/base 58G /pgdb/9.6/main/pg_xlog 72G  

डेटाबेस व्यवस्थापक आमतौर पर जानते हैं कि यह निर्देशिका क्या है, और वे इसे स्पर्श नहीं करते हैं - यह मौजूद है और मौजूद है। लेकिन डेवलपर, खासकर अगर वह मंचन को देखता है, तो अपने सिर को खरोंचता है और सोचता है:

- कुछ प्रकार के लॉग ... चलो pg_xlog हटाएं!

निर्देशिका को हटाता है, डेटाबेस काम करना बंद कर देता है । लेन-देन लॉग को हटाने के बाद तुरंत आपको Google को डेटाबेस को कैसे उठाना है, यह बताना होगा।



दूसरा उदाहरण । फिर से, हम निगरानी करते हैं और देखते हैं कि पर्याप्त जगह नहीं है। इस बार जगह पर किसी तरह के आधार का कब्जा है।

 $ du -csh -t 100M /pgdb/9.6/main/* 70G /pgdb/9.6/main/base 2G /pgdb/9.6/main/pg_xlog 72G  

हम इस बात की तलाश कर रहे हैं कि कौन सा डेटाबेस सबसे अधिक स्थान लेता है, कौन से टेबल और इंडेक्स।



यह पता चला है कि यह ऐतिहासिक लॉग के साथ एक तालिका है। हमें ऐतिहासिक लॉग की कभी आवश्यकता नहीं थी। वे सिर्फ मामले में लिखे गए हैं, और अगर यह जगह के साथ समस्या के लिए नहीं थे, तो कोई भी दूसरे आने तक उन्हें नहीं देखेगा:

- चलो सब कुछ है कि मिमी ... पुराने अक्टूबर से साफ!

अपडेट अनुरोध करें, इसे चलाएं, यह काम करेगा और कुछ लाइनों को हटा देगा।

 =# DELETE FROM history_log -# WHERE created_at < «2018-10-01»; DELETE 165517399 Time: 585478.451 ms 

क्वेरी 10 मिनट के लिए चलती है, लेकिन तालिका अभी भी उतनी ही जगह लेती है।

PostgreSQL तालिका से पंक्तियों को हटाता है - सब कुछ सही है, लेकिन यह ऑपरेटिंग सिस्टम के लिए जगह नहीं लौटाता है। PostgreSQL का यह व्यवहार अधिकांश डेवलपर्स के लिए अज्ञात है और यह बहुत आश्चर्यजनक हो सकता है।

तीसरा उदाहरण । उदाहरण के लिए, ORM ने एक दिलचस्प अनुरोध किया। आमतौर पर हर कोई ORM को "खराब" प्रश्न बनाने के लिए दोषी ठहराता है जो कुछ तालिकाओं को पढ़ता है।

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

लेकिन यह सब नहीं है। आप PostgerSQL की अन्य विशेषताओं को याद कर सकते हैं।

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

सबसे अधिक बार, PostgreSQL में डिस्क स्थान या डिस्क प्रदर्शन की कमी होती है। सौभाग्य से, प्रोसेसर, मेमोरी और एक नेटवर्क के साथ, एक नियम के रूप में, सब कुछ कमोबेश क्रम में है।

कैसे हो? निगरानी और योजना की आवश्यकता है! यह स्पष्ट प्रतीत होता है, लेकिन किसी कारण से, ज्यादातर मामलों में, कोई भी एक आधार की योजना नहीं बनाता है, और निगरानी उन सभी को कवर नहीं करती है जिन्हें पोस्टग्रेसीक्यूएल के संचालन के दौरान निगरानी करने की आवश्यकता होती है। स्पष्ट नियमों का एक सेट है, जिसके साथ सब कुछ अच्छा काम करेगा, और "यादृच्छिक पर" नहीं।

आयोजन

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

हमेशा एक डेटा स्कीमा की योजना बनाएं । डेटाबेस को मत लिखें कि आपको संदेह है कि क्या आवश्यक है - गारंटी की आवश्यकता नहीं है। एक सरल उदाहरण हमारे ग्राहकों में से एक की थोड़ा संशोधित तालिका है।



यह एक लॉग टेबल है जिसमें टाइप जसन का डेटा कॉलम होता है। सापेक्ष रूप से, आप इस कॉलम में कुछ भी लिख सकते हैं। इस तालिका के अंतिम रिकॉर्ड से यह देखा जा सकता है कि लॉग 8 एमबी पर हैं। PostgreSQL को इस लंबाई के रिकॉर्ड को संग्रहीत करने में कोई समस्या नहीं है। PostgreSQL में बहुत अच्छा स्टोरेज है जो इस तरह के रिकॉर्ड को चबाता है।

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

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

10 मिनट में डेटा हटाने के उदाहरण में, DELETE को DROP TABLE बदला जा सकता है - ऐसी परिस्थितियों में इस तरह के ऑपरेशन में केवल कुछ मिलीसेकंड लगेगा।

जब डेटा को विभाजन द्वारा सॉर्ट किया जाता है, तो विभाजन को कुछ मिलीसेकेंड में शाब्दिक रूप से हटा दिया जाता है, और ओएस तुरंत खत्म हो जाता है। ऐतिहासिक डेटा को प्रबंधित करना आसान, आसान और सुरक्षित है।

निगरानी

निगरानी एक अलग विषय है, लेकिन डेटाबेस के दृष्टिकोण से ऐसी सिफारिशें हैं जो लेख के एक खंड में फिट हो सकती हैं।

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

बहुत सारे PostgreSQL मॉनिटरिंग विकल्प हैं, हर स्वाद के लिए हैं। यहां कुछ बिंदु दिए गए हैं जो मौजूद होने चाहिए।

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

अधिक जानकारी के लिए, Highgad ++ साइबेरिया और PostgreSQL विकी में निगरानी पृष्ठ के साथ "पोस्टग्रेसीक्यू मॉनिटरिंग बेसिक्स" रिपोर्ट देखें।

जब हमने सब कुछ योजनाबद्ध किया और निगरानी के साथ "खुद को कवर किया", तब भी हम कुछ समस्याओं का सामना कर सकते हैं।

स्केलिंग

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

"मुझे आधार का पता दें, फिर मैं खुद।" © बेनामी डेवलपर।

जब डेवलपर इस डेटाबेस में काम करने वाले प्रश्नों को लिखना शुरू करता है, तो विषय की अज्ञानता काफी दिलचस्प परिणाम देती है। विलोम जब प्रश्न लिखते हैं तो कभी-कभी तेजस्वी प्रभाव देते हैं।

लेनदेन दो प्रकार के होते हैं। ओएलटीपी लेनदेन तेज, कम, हल्के होते हैं जो एक मिलीसेकंड के अंश लेते हैं। वे बहुत जल्दी काम करते हैं, और उनमें से बहुत सारे हैं। OLAP - विश्लेषणात्मक प्रश्न - धीमे, लंबे, भारी, तालिकाओं के बड़े सरणियों को पढ़ें और आंकड़े पढ़ें।

पिछले 2-3 वर्षों में, संक्षिप्त रूप से HTAP अक्सर लगता है - हाइब्रिड लेनदेन / विश्लेषणात्मक प्रसंस्करण या हाइब्रिड लेन-देन-विश्लेषणात्मक प्रसंस्करण । यदि आपके पास OLAP और OLTP अनुरोधों को स्केल करने और विविधता के बारे में सोचने का समय नहीं है, तो आप कह सकते हैं: "हमारे पास HTAP!" लेकिन त्रुटियों का अनुभव और दर्द बताते हैं कि आखिरकार, विभिन्न प्रकार के अनुरोधों को एक-दूसरे से अलग-अलग रहना चाहिए, क्योंकि लंबे समय तक OLAP अनुरोध लाइट OLTP अनुरोधों को अवरुद्ध करते हैं।

इसलिए हम इस सवाल पर आते हैं कि कैसे पोस्टग्रेक्यूएल को स्केल किया जाए ताकि लोड को फैलाया जा सके, और हर कोई संतुष्ट था।

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

साथ ही, आप अधिक प्रतिकृतियों को व्यक्तिगत प्रतिकृतियों से जोड़ सकते हैं और कैस्केड प्रतिकृति प्राप्त कर सकते हैं । उदाहरण के लिए, अलग-अलग उपयोगकर्ता समूह या एप्लिकेशन, जो एनालिटिक्स पढ़ते हैं, को एक अलग प्रतिकृति में स्थानांतरित किया जा सकता है।



तार्किक प्रकाशन, सदस्यता - तार्किक प्रकाशन और सदस्यता के तंत्र का अर्थ है अलग-अलग डेटाबेस और तालिकाओं के सेट के साथ कई स्वतंत्र पोस्टग्रेक्यूएल-सर्वर की उपस्थिति। तालिकाओं के इन सेटों को पड़ोसी डेटाबेस से जोड़ा जा सकता है, वे उन अनुप्रयोगों को दिखाई देंगे जो उन्हें सामान्य रूप से उपयोग कर सकते हैं। यही है, स्रोत में होने वाले सभी परिवर्तन गंतव्य बेस पर दोहराए जाते हैं और वहां दिखाई देते हैं। PostgreSQL 10 के साथ बढ़िया काम करता है।



विदेशी तालिकाओं, घोषणा विभाजन - घोषणात्मक विभाजन और बाहरी तालिकाओं । आप कई PostgreSQL ले सकते हैं और वहां टेबल के कई सेट बना सकते हैं जो वांछित डेटा पर्वतमाला को संग्रहीत करेंगे। यह एक विशिष्ट वर्ष के लिए डेटा हो सकता है या किसी भी सीमा से अधिक डेटा एकत्र किया जा सकता है।



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



यह सब अलग-अलग PostgreSQL प्रतिकृति टोपोलॉजी के साथ आने के लिए, इसे फैलाने वाले कॉन्फ़िगरेशन में जोड़ा जा सकता है, लेकिन यह कैसे काम करता है और इसे कैसे प्रबंधित किया जाए यह एक अलग रिपोर्ट का विषय है।

कहाँ से शुरू करें?

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

अगला कदम संतुलन है । हमारे पास अभी भी एक ही लाइन है जो कि डिफॉल्ट में है, जिसे डेवलपर ऑपरेट करता है। उसे ऐसी जगह चाहिए, जहां वह लिखकर पढ़ेगा। यहां कई विकल्प हैं।

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

• DNS राउंड रॉबिन , मेरी राय में, एक बहुत ही सुविधाजनक कार्यान्वयन नहीं है, क्योंकि कभी-कभी यह लंबे समय तक काम करता है और विफलता के मामलों में सर्वर के बीच विज़ार्ड भूमिकाओं को बदलते समय आवश्यक समय नहीं देता है।
• एक और अधिक दिलचस्प विकल्प Keepalived और HAProxy का उपयोग करना है । मास्टर के लिए वर्चुअल पते और प्रतिकृतियों के सेट को HAProxy सर्वर के बीच फेंक दिया जाता है, और HAProxy पहले से ही ट्रैफ़िक को संतुलित कर रहा है।
• Patroni, DCS जैसे कुछ के साथ संयोजन के रूप में ZooKeeper, etcd, Consul - सबसे दिलचस्प विकल्प, मेरी राय में। यही है, सेवा की खोज उस जानकारी के लिए जिम्मेदार है जो अब मास्टर है और जो प्रतिकृति है। Patroni PostgreSQL का एक क्लस्टर प्रबंधित करता है, स्विचिंग करता है - यदि टोपोलॉजी बदल गई है, तो यह जानकारी सेवा खोज में दिखाई देगी, और एप्लिकेशन जल्दी से वर्तमान टोपोलॉजी का पता लगा सकते हैं।

और प्रतिकृति के साथ बारीकियां हैं, जिनमें से सबसे आम प्रतिकृति लैग है । आप इसे GitLab की तरह कर सकते हैं, और जब अंतराल जम जाता है, तो बस आधार को छोड़ दें। लेकिन हमारे पास व्यापक निगरानी है - हम इसे देखते हैं और लंबे लेनदेन को देखते हैं।

अनुप्रयोग और DBMS लेनदेन

सामान्य, धीमी और निष्क्रिय लेन-देन में परिणाम:

• उत्पादकता में कमी - एक तेज स्पस्मोडिक के लिए नहीं, लेकिन चिकनी;
  
• ताले और गतिरोध , क्योंकि लंबे लेनदेन पंक्तियों पर ताले रखते हैं और अन्य लेनदेन को काम करने से रोकते हैं;
  
• 50 * बैकएंड , इंटरफ़ेस त्रुटियों या कहीं और पर HTTP त्रुटियां ।
  

आइए थोड़ा सिद्धांत देखें कि ये समस्याएं कैसे उत्पन्न होती हैं, और लंबी और निष्क्रिय लेनदेन का तंत्र हानिकारक क्यों है।

PostgreSQL में MVCC है - अपेक्षाकृत बोलने वाला, एक डेटाबेस इंजन। यह ग्राहकों को एक दूसरे के साथ हस्तक्षेप किए बिना डेटा के साथ प्रतिस्पर्धी रूप से काम करने की अनुमति देता है: पाठक पाठकों के साथ हस्तक्षेप नहीं करते हैं, और लेखक लेखकों के साथ हस्तक्षेप नहीं करते हैं। बेशक, कुछ अपवाद हैं, लेकिन इस मामले में वे महत्वपूर्ण नहीं हैं।

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

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

जितना लंबा लेन-देन, उतना अधिक रद्दी और कम प्रदर्शन।

"किसे दोष देना है?" के दृष्टिकोण से, ऐप लंबे लेनदेन की उपस्थिति के लिए दोषी है। यदि डेटाबेस अपने आप ही मौजूद रहेगा, तो कहीं से भी लंबी, कुछ भी लेन-देन नहीं किया जाएगा। व्यवहार में, निष्क्रिय लेनदेन की उपस्थिति के लिए निम्नलिखित विकल्प हैं।

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

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

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

आइए देखें कि इन मामलों में क्या करना है।

• हमारे पास निगरानी है, तदनुसार, हमें निगरानी में अलर्ट की आवश्यकता है। कोई भी लेन-देन जो एक घंटे से अधिक समय तक लटका रहता है और कुछ भी नहीं करता है, यह देखने का अवसर नहीं है कि यह कहां से आया है और यह समझना है कि क्या गलत है।
• अगला कदम ताज में कार्य (pg_terminate_backend (pid)) के माध्यम से ऐसे लेनदेन को शूट करना है या PostgreSQL कॉन्फ़िगरेशन में कॉन्फ़िगर करना है। 10-30 मिनट के थ्रेसहोल्ड की आवश्यकता होती है, जिसके बाद लेनदेन स्वचालित रूप से पूरा हो जाता है।
• आवेदन को फिर से भरना । बेशक, आपको यह पता लगाने की आवश्यकता है कि निष्क्रिय लेनदेन कहाँ से आते हैं, वे क्यों होते हैं और ऐसे स्थानों को खत्म करते हैं।

हर कीमत पर लंबे लेनदेन से बचें, क्योंकि वे डेटाबेस प्रदर्शन को बहुत प्रभावित करते हैं।

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

साइकिल निर्माण

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

ऐसे कार्यों का सार एक ही है - उन्हें बाद के लिए स्थगित कर दिया जाता है। डेटाबेस डेटाबेस में दिखाई देते हैं जो सिर्फ कतारों को निष्पादित करते हैं।



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

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

प्रसंस्करण समय बढ़ रहा है - एक लंबा लेनदेन पंक्तियों के पुराने संस्करणों पर ताला लगाता है या वैक्यूम को साफ करने से रोकता है। जब तालिका आकार में बढ़ती है, तो प्रसंस्करण समय भी बढ़ जाता है, क्योंकि आपको कचरे के साथ कई पृष्ठ पढ़ने की आवश्यकता होती है। समय बढ़ता है, और कुछ बिंदु पर कतार बिल्कुल काम करना बंद कर देती है ।

नीचे हमारे ग्राहकों में से एक का एक उदाहरण है, जिनकी एक कतार थी। सभी अनुरोध कतार से संबंधित हैं।



इन अनुरोधों के निष्पादन समय पर ध्यान दें - सभी लेकिन उनमें से एक बीस सेकंड से अधिक समय तक काम करता है।

इन समस्याओं को हल करने के लिए, PostgreSQL के लिए एक कतार प्रबंधक, Skytools PgQ , का आविष्कार बहुत पहले किया गया था। अपनी बाइक को फिर से स्थापित न करें - PgQ लें, इसे एक बार सेट करें और लाइनों के बारे में भूल जाएं।

सच है, उसके पास विशेषताएं भी हैं। Skytools PgQ के पास बहुत कम दस्तावेज हैं । आधिकारिक पृष्ठ को पढ़ने के बाद, किसी को यह महसूस होता है कि उसे कुछ भी समझ नहीं आया। जब आप कुछ करने की कोशिश करते हैं तो भावना बढ़ती है। सब कुछ काम करता है, लेकिन यह कैसे काम करता है स्पष्ट नहीं है । किसी तरह का जेडी मैजिक। लेकिन मेलिंग-सूचियों में बहुत सारी जानकारी मिल सकती है। यह बहुत सुविधाजनक प्रारूप नहीं है, लेकिन बहुत सारी दिलचस्प चीजें हैं और आपको इन चादरों को पढ़ना होगा।

विपक्ष के बावजूद, स्काईटल्स पीजीक्यू "सेट अप एंड भूल" के सिद्धांत पर काम करता है। , , , . PgQ , . PgQ , .

, - — , . .

PgQ. , PostgreSQL, , , PgQ . , .

, . , , , - , , , . , , , alter.

auto-failover — PostgreSQL - , , . , auto-failover.

Split-brain . PostgreSQL , , — . , . PostgreSQL fencing, Kubernets . - , . Split-brain.



. GitHub Split-brain, .

Cascade failover . , . , .



, . , .



— failover.

auto-failover, .

Bash — , . , , . - , , . .

Ansible playbooks — bash- . , , .

Patroni — , , auto-failover, , service discovery.

PAF — Pacemaker . auto-failover PostgreSQL, Pacemaker.

Stolon . Kubernetes, . Stolon Patroni, .

Docker Kubernetes . , .



, . « Kubernetes...» .

— stateful , - . कहाँ? . Open Source: CEPH, GlusterFS, LinStor DRBD. , , , .

— . , Kubernetes, CEPH. — . , .

• , .
• latency . latency — .
• . Kubernetes , - . , shared storage Kubernetes, . - .

, Kubernetes Docker staging dev- . , , Kubernetes .



, local volumes — , streaming replication — , PostgreSQL- , — , . : Zalando Crunchy .

, . issues pull requests. , , .

परिणाम

SSD — , .

. JSON 8 — , .

, . PostgreSQL, .

— Postgres is ready . . PostgreSQL , . : streaming replication; publications, subscriptions; foreign Tables; declarative partitioning .

. , .

-, , — . . , Skytools PgQ!

Kubernetes, local volumes, streaming replication PostgreSQL . - , , .

. , 24 25 HighLoad++ Siberia , , . 38 — !