ओडिसी रोडमैप: हम एक कनेक्शन पूलर से और क्या चाहते हैं I एंड्री बोरोडिन (2019)

अपनी रिपोर्ट में, एंड्री बोरोडिन आपको बताएंगे कि कनेक्शन पूलर को डिजाइन करते समय उन्होंने पीजीबाउंसर को स्केल करने के अनुभव को कैसे ध्यान में रखा। ओडिसी, जैसे ही उन्होंने इसे उत्पादन में उतारा। इसके अलावा, हम चर्चा करेंगे कि पुलर के कौन से कार्य हम नए संस्करणों में देखना चाहेंगे: यह हमारे लिए न केवल हमारी जरूरतों को पूरा करने के लिए महत्वपूर्ण है, बल्कि उपयोगकर्ता समुदाय को विकसित करने के लिए भी महत्वपूर्ण है। Одиссея.

वीडियो:

नमस्ते! मेरा नाम एंड्रयू है।

यांडेक्स में, मैं ओपन सोर्स डेटाबेस विकसित करता हूं। और आज हमारे पास कनेक्शन पूलर कनेक्शन के बारे में एक विषय है।

यदि आप जानते हैं कि रूसी में कनेक्शन पूलर को कैसे कॉल किया जाता है, तो मुझे बताएं। मैं वास्तव में एक अच्छा तकनीकी शब्द ढूंढना चाहता हूं जिसे तकनीकी साहित्य में स्थापित किया जाना चाहिए।

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

यांडेक्स के पास पोस्टग्रेज है। कई Yandex सेवाएँ Yandex.Cloud में रहती हैं। और हमारे पास कई पेटाबाइट डेटा हैं जो पोस्टग्रेज़ में प्रति सेकंड कम से कम दस लाख अनुरोध उत्पन्न करते हैं।

और हम सभी सेवाओं के लिए एक काफी मानक क्लस्टर प्रदान करते हैं - यह नोड का मुख्य प्राथमिक नोड है, सामान्य दो प्रतिकृतियां (सिंक्रोनस और एसिंक्रोनस), बैकअप, प्रतिकृति पर पढ़ने के अनुरोधों की स्केलिंग।

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

कनेक्शन पूलर का मुख्य उद्देश्य क्या है?

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

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

3 संभावित दृष्टिकोण हैं:

• आवेदन पक्ष पर.
• डेटाबेस पक्ष पर.
• और बीच में, यानी, सभी प्रकार के संयोजन।

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

एप्लिकेशन-साइड पूल सबसे आसान तरीका है। और लगभग सभी क्लाइंट ड्राइवर आपको एक तरीका प्रदान करते हैं: अपने लाखों कनेक्शनों को डेटाबेस में कई दर्जन कनेक्शनों के रूप में कोड में प्रस्तुत करें।

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

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

अगर हम प्रॉक्सी पूलर्स की बात करें तो दो पूलर्स हैं जो बहुत सारे काम कर सकते हैं। वे केवल पूलर्स नहीं हैं. वे पूलर + अधिक शानदार कार्यक्षमता वाले हैं। यह पीजीपूल и कुरकुरा-प्रॉक्सी.

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

यह हमारे उद्देश्यों के लिए बहुत उपयुक्त नहीं है, इसलिए हम PgBouncer का उपयोग करते हैं, जो लेनदेन पूलिंग को लागू करता है, यानी सर्वर कनेक्शन केवल लेनदेन की अवधि के लिए क्लाइंट कनेक्शन से मेल खाता है।

और हमारे कार्यभार में, यह सच है। लेकिन कुछ समस्याएं हैं.

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

बेशक आप application_name_add_host का उपयोग कर सकते हैं। यह बाउंसर की ओर से एप्लिकेशन_नाम में आईपी एड्रेस जोड़ने का एक तरीका है। लेकिन एप्लिकेशन_नाम एक अतिरिक्त कनेक्शन द्वारा सेट किया गया है।

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

इसके अलावा, बाउंसर में आप एक पूल को सीमित नहीं कर सकते, यानी प्रति विशिष्ट उपयोगकर्ता, प्रति विशिष्ट डेटाबेस डेटाबेस कनेक्शन की संख्या।

इससे क्या होता है? आपके पास C++ में लिखी गई एक भरी हुई सेवा है और कहीं पास में एक नोड पर एक छोटी सेवा है जो डेटाबेस के साथ कुछ भी भयानक नहीं करती है, लेकिन इसका ड्राइवर पागल हो जाता है। यह 20 कनेक्शन खोलता है और बाकी सब प्रतीक्षा करेगा। आपका कोड भी सामान्य है.

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

पोस्टग्रेज़ की ओर से ऐसा करना संभव होगा, यानी कनेक्शन की संख्या के आधार पर डेटाबेस में भूमिकाओं को सीमित करना।

लेकिन फिर आप यह समझने की क्षमता खो देते हैं कि आपका सर्वर से कोई कनेक्शन क्यों नहीं है। PgBouncer कोई कनेक्शन त्रुटि नहीं देता है, यह हमेशा वही जानकारी लौटाता है। और आप समझ नहीं सकते: हो सकता है कि आपका पासवर्ड बदल गया हो, हो सकता है कि डेटाबेस खो गया हो, हो सकता है कि कुछ गलत हो। लेकिन कोई निदान नहीं है. यदि कोई सत्र स्थापित नहीं किया जा सकता है, तो आपको पता नहीं चलेगा कि इसे क्यों स्थापित नहीं किया जा सकता है।

एक निश्चित बिंदु पर, आप एप्लिकेशन ग्राफ़ को देखते हैं और देखते हैं कि एप्लिकेशन काम नहीं कर रहा है।

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

हम इस निष्कर्ष पर पहुंचे हैं कि हमें और अधिक PgBouncers की आवश्यकता है।

https://lwn.net/Articles/542629/

बाउंसर को थोड़ा पैच किया गया है।

और उन्होंने इसे इसलिए बनाया ताकि टीसीपी पोर्ट का पुन: उपयोग करके कई बाउंसर उठाए जा सकें। और ऑपरेटिंग सिस्टम स्वचालित रूप से राउंड-रॉबिन का उपयोग करके उनके बीच आने वाले टीसीपी कनेक्शन को स्थानांतरित करता है।

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

और एक निश्चित क्षण में आप देख सकते हैं कि ये तीन बाउंसर अपना कोर 3% तक खा जाते हैं। आपको कुछ बाउंसरों की आवश्यकता है। क्यों?

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

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

और बड़ी संख्या में टीएलएस हैंडशेक अब बाउंसर को नमस्ते नहीं कहेगा, लेकिन उसका गला दबा देगा। समय समाप्ति के कारण, आने वाले कनेक्शनों की लहर अबाधित हो सकती है। यदि आप घातीय बैकऑफ़ के बिना आधार पर पुनः प्रयास करते हैं, तो वे एक सुसंगत तरंग में बार-बार नहीं आएंगे।

यहां 16 पीजीबाउंसरों का एक उदाहरण दिया गया है जो 16% पर 100 कोर लोड करते हैं।

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

इस कॉन्फ़िगरेशन में, एक सुचारू पुनरारंभ संभव है। आप इन सभी 18 बाउंसरों को एक-एक करके पुनः आरंभ कर सकते हैं। लेकिन ऐसे कॉन्फ़िगरेशन को बनाए रखना काफी कठिन है। Sysadmins, DevOps, और वे लोग जो वास्तव में इस सर्वर के लिए ज़िम्मेदार हैं, इस व्यवस्था से बहुत खुश नहीं होंगे।

ऐसा प्रतीत होता है कि हमारे सभी सुधारों को ओपन सोर्स में बढ़ावा दिया जा सकता है, लेकिन बाउंसर बहुत अच्छी तरह से समर्थित नहीं है। उदाहरण के लिए, एक पोर्ट पर कई PgBouncers चलाने की क्षमता एक महीने पहले प्रतिबद्ध थी। कई वर्ष पहले इस सुविधा को हटाने का अनुरोध किया गया था।

https://www.postgresql.org/docs/current/libpq-cancel.html

https://github.com/pgbouncer/pgbouncer/pull/79

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

इसे ठीक कर दिया गया है और इस समस्या को अभी तक बाउंसर के अपस्ट्रीम में विलय नहीं किया गया है।

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

हमने मल्टीथ्रेडिंग को मुख्य कार्य के रूप में निर्धारित किया है। हमें आने वाले टीएलएस कनेक्शन की लहर को अच्छी तरह से संभालने में सक्षम होने की आवश्यकता है।

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

परिणामस्वरूप, हमारे पास एक थ्रेड है जो टीसीपी स्वीकार करता है और राउंड-रॉबिन कई श्रमिकों को टीपीसी कनेक्शन भेजता है।

इस स्थिति में, प्रत्येक क्लाइंट कनेक्शन हमेशा एक प्रोसेसर पर चलता है। और यह आपको इसे कैश-अनुकूल बनाने की अनुमति देता है।

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

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

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

हम Yandex.Cloud के हित में काम करते हैं। और यदि आप प्रबंधित PostgreSQL का उपयोग करते हैं और एक कनेक्शन पूलर स्थापित किया है, तो आप तार्किक प्रतिकृति का उपयोग करके बाहर की ओर तार्किक प्रतिकृति बना सकते हैं, यानी, यदि आप चाहें तो हमें छोड़ दें। बाउंसर तार्किक प्रतिकृति प्रवाह को बाहर नहीं छोड़ेगा।

यह तार्किक प्रतिकृति स्थापित करने का एक उदाहरण है.

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

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

और, निःसंदेह, हमें अग्रेषित करने में त्रुटि हुई है। हम डेटाबेस द्वारा रिपोर्ट की गई त्रुटि वापस कर देंगे। आपको इस बारे में जानकारी प्राप्त होगी कि आप डेटाबेस में क्यों शामिल नहीं हैं, और इतना ही नहीं कि आप इसमें शामिल नहीं हैं।

यदि आपको PgBouncer के साथ 100% अनुकूलता की आवश्यकता है तो यह सुविधा अक्षम है। हम सुरक्षित रहने के लिए बाउंसर की तरह ही व्यवहार कर सकते हैं।

डिज़ाइन

ओडिसी स्रोत कोड के बारे में कुछ शब्द।

https://github.com/yandex/odyssey/pull/66

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

https://github.com/yandex/odyssey/pull/73 - पहले से ही जमे हुए

इसके अलावा, PgBouncer में नई सुविधाओं में से एक SCRAM प्रमाणीकरण के लिए समर्थन है, जिसे एक ऐसे व्यक्ति द्वारा भी हमारे पास लाया गया था जो Yandex.Cloud में काम नहीं करता है। दोनों जटिल कार्यक्षमता वाले और महत्वपूर्ण हैं।

इसलिए, यदि आप भी अब थोड़ा कोड लिखना चाहते हैं तो मैं आपको बताना चाहूंगा कि ओडिसी किस चीज से बना है।

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

मैकिनेरियम लाइब्रेरी एक थ्रेड कार्यान्वयन लाइब्रेरी है। इस मैकिनेरियम का एक छोटा सा टुकड़ा असेंबली भाषा में लिखा गया है। लेकिन चौंकिये मत, केवल 15 पंक्तियाँ हैं।

ओडिसी वास्तुकला. एक मुख्य मशीन है जिस पर कोरटाइन चल रहे हैं। यह मशीन आने वाले टीसीपी कनेक्शनों को स्वीकार करने और उन्हें श्रमिकों के बीच वितरित करने का कार्य करती है।

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

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

इसके अलावा, ऐसे कई ड्राइवर हैं जिनकी अपनी टेस्टिंग होती है। और हम ओडिसी का परीक्षण करने के लिए उनके परीक्षणों का उपयोग करते हैं।

इसके अलावा, हमारे कैस्केड कॉन्फ़िगरेशन के कारण, हमें विभिन्न बंडलों का परीक्षण करना होगा: पोस्टग्रेस + ओडिसी, पीजीबाउंसर + ओडिसी, ओडिसी + ओडिसी यह सुनिश्चित करने के लिए कि यदि ओडिसी कैस्केड के किसी भी हिस्से में समाप्त हो गया है, तो यह अभी भी काम करता है जैसा कि हम उम्मीद करते हैं.

जेली

हम उत्पादन में ओडिसी का उपयोग करते हैं। और यह उचित नहीं होगा यदि मैं कहूँ कि सब कुछ बस काम करता है। नहीं, यानी हाँ, लेकिन हमेशा नहीं। उदाहरण के लिए, उत्पादन में सब कुछ ठीक-ठाक चल रहा था, तभी PostgreSQL प्रोफेशनल के हमारे मित्र आए और कहा कि हमारी मेमोरी लीक हो गई है। वे वास्तव में थे, हमने उन्हें ठीक किया। लेकिन यह सरल था.

तब हमें पता चला कि कनेक्शन पूलर में इनकमिंग टीएलएस कनेक्शन और आउटगोइंग टीएलएस कनेक्शन हैं। और कनेक्शन के लिए क्लाइंट प्रमाणपत्र और सर्वर प्रमाणपत्र की आवश्यकता होती है।

बाउंसर और ओडिसी सर्वर प्रमाणपत्रों को उनके pcache द्वारा दोबारा पढ़ा जाता है, लेकिन क्लाइंट प्रमाणपत्रों को pcache से दोबारा पढ़ने की आवश्यकता नहीं होती है, क्योंकि हमारा स्केलेबल ओडिसी अंततः इस प्रमाणपत्र को पढ़ने के सिस्टम प्रदर्शन में चलता है। यह हमारे लिए आश्चर्य की बात थी, क्योंकि उसे विरोध करने में देर नहीं लगी। सबसे पहले यह रैखिक रूप से बढ़ा, लेकिन 20 आने वाले एक साथ कनेक्शन के बाद यह समस्या सामने आई।

प्लग करने योग्य प्रमाणीकरण विधि अंतर्निहित लूनक्स टूल का उपयोग करके प्रमाणित करने की क्षमता है। PgBouncer में इसे इस तरह से कार्यान्वित किया जाता है कि PAM से प्रतिक्रिया की प्रतीक्षा करने के लिए एक अलग थ्रेड होता है और एक मुख्य PgBouncer थ्रेड होता है जो वर्तमान कनेक्शन की सेवा करता है और उन्हें PAM थ्रेड में रहने के लिए कह सकता है।

हमने इसे एक साधारण कारण से लागू नहीं किया। हमारे पास बहुत सारे धागे हैं. हमें इसकी ज़रूरत क्यों है?

यह अंततः समस्याएँ पैदा कर सकता है यदि आपके पास PAM प्रमाणीकरण और गैर-PAM प्रमाणीकरण है, तो PAM प्रमाणीकरण की एक बड़ी लहर गैर-PAM प्रमाणीकरण में काफी देरी कर सकती है। यह उन चीज़ों में से एक है जिन्हें हमने ठीक नहीं किया है। लेकिन अगर आप इसे ठीक करना चाहते हैं तो ऐसा कर सकते हैं.

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

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

यदि वे सभी एक ही समय में डेटाबेस में प्रवेश नहीं कर सकते हैं, तो वे डेटाबेस में प्रवेश नहीं कर सकते हैं, क्योंकि यह सब गैर-घातीय पुनः प्रयास द्वारा कवर किया जा सकता है।

हम इस निष्कर्ष पर पहुंचे कि हमने इस योजना को पीजीबाउंसर से इस तथ्य के साथ कॉपी किया है कि हमने उन टीसीपी कनेक्शनों की संख्या को कम कर दिया है जिन्हें हम स्वीकार करते हैं।

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

रोडमैप

आप भविष्य में ओडिसी में क्या देखना चाहेंगे? हम अपना विकास करने के लिए क्या तैयार हैं और हम समुदाय से क्या अपेक्षा करते हैं?

अगस्त 2019 तक।

अगस्त में ओडिसी रोडमैप इस तरह दिखता था:

• हम SCRAM और PAM प्रमाणीकरण चाहते थे।
• हम पढ़ने के अनुरोधों को स्टैंडबाय पर अग्रेषित करना चाहते थे।
• मैं एक ऑनलाइन पुनरारंभ चाहूंगा.
• और सर्वर पर रुकने की क्षमता।

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

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

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

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

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

कार्यान्वयन के लिए कोई समय-सीमा बताना कठिन है, क्योंकि यह खुला स्रोत है। लेकिन, मुझे आशा है, PgBouncer के मेरे सहकर्मियों की तरह 2,5 साल नहीं। यही वह विशेषता है जिसे मैं ओडिसी में देखना चाहूंगा।

समुदाय में, लोगों ने तैयार कथन के लिए समर्थन के बारे में पूछा. अब आप दो तरह से तैयार स्टेटमेंट बना सकते हैं. सबसे पहले, आप SQL कमांड निष्पादित कर सकते हैं, जिसका नाम है "तैयार"। इस SQL ​​कमांड को समझने के लिए, हमें बाउंसर पक्ष पर SQL को समझना सीखना होगा। यह एक अतिशयोक्ति होगी, क्योंकि यह अतिशयोक्ति है, क्योंकि हमें संपूर्ण पार्सर की आवश्यकता है। हम प्रत्येक SQL कमांड को पार्स नहीं कर सकते.

लेकिन proto3 पर संदेश प्रोटोकॉल स्तर पर एक तैयार कथन है। और यह वह स्थान है जब यह जानकारी कि एक तैयार कथन बनाया जा रहा है, एक संरचित रूप में आती है। और हम इस समझ का समर्थन कर सकते हैं कि कुछ सर्वर कनेक्शन पर क्लाइंट ने तैयार स्टेटमेंट बनाने के लिए कहा था। और भले ही लेनदेन बंद हो जाए, फिर भी हमें सर्वर और क्लाइंट के बीच कनेक्टिविटी बनाए रखने की आवश्यकता है।

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

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

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

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

सबसे महत्वपूर्ण बात यह है कि मुझे संस्करण 1.0 चाहिए (संस्करण 1.1 पहले ही जारी किया जा चुका है)। तथ्य यह है कि ओडिसी अब संस्करण 1.0rc, यानी रिलीज़ कैंडिडेट में है। और स्मृति रिसाव को छोड़कर, मेरे द्वारा सूचीबद्ध सभी समस्याओं को बिल्कुल उसी संस्करण के साथ ठीक कर दिया गया था।

संस्करण 1.0 हमारे लिए क्या मायने रखेगा? हम ओडिसी को अपने ठिकानों तक पहुंचा रहे हैं। यह हमारे डेटाबेस पर पहले से ही चल रहा है, लेकिन जब यह प्रति सेकंड 1 अनुरोधों के बिंदु तक पहुंच जाता है, तो हम कह सकते हैं कि यह रिलीज़ संस्करण है और यह एक ऐसा संस्करण है जिसे 000 कहा जा सकता है।

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

मैं आपके पुल अनुरोध की प्रतीक्षा कर रहा हूं. मैं यह भी सुनना चाहूँगा कि आपको बाउंसर से क्या समस्याएँ हैं। आइए उन पर चर्चा करें. हो सकता है कि हम आपके लिए आवश्यक कुछ फ़ंक्शन कार्यान्वित कर सकें।

यह मेरे हिस्से का अंत है, मैं आपकी बात सुनना चाहूंगा। धन्यवाद!

सवाल

यदि मैं अपना स्वयं का एप्लिकेशन_नाम सेट करता हूं, तो क्या इसे ओडिसी में लेनदेन पूलिंग सहित, सही ढंग से अग्रेषित किया जाएगा?

ओडिसी या बाउंसर?

ओडिसी में. बाउंसर में इसे फेंका जाता है.

हम एक सेट करेंगे.

और यदि मेरा वास्तविक कनेक्शन अन्य कनेक्शनों पर कूदता है, तो क्या यह प्रसारित होगा?

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

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

हाँ, मुझे यह चर्चा याद आ रही है। अब वहां कई भंडार हैं. लेकिन उनके बीच कोई स्विचिंग नहीं है. अपनी ओर से, हमें सर्वर का सर्वेक्षण करना चाहिए कि यह अभी भी सक्रिय है और समझें कि एक विफलता हुई है, जो pg_recovery को कॉल करेगा। मेरे पास यह समझने का एक मानक तरीका है कि हम गुरु के पास नहीं आए हैं। और क्या हमें गलतियों से किसी तरह समझना चाहिए या क्या? यानी आइडिया दिलचस्प है, इस पर चर्चा हो रही है. अधिक टिप्पणियाँ लिखें. यदि आपके पास ऐसे कर्मचारी हैं जो सी जानते हैं, तो यह बहुत अच्छा है।

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

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

हाँ, यह सच है। पीसीचे में आपके इच्छित डेटा ब्लॉक नहीं होंगे, वास्तविक कैश में आपके इच्छित तालिकाओं के बारे में जानकारी नहीं होगी, योजनाओं में पार्स की गई क्वेरीज़ नहीं होंगी, वहां कुछ भी नहीं होगा।

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

मुझे विचार मिल गया. सही तरीका यह होगा कि पहले प्रतिकृति पर प्रश्नों का एक छोटा प्रतिशत चलाया जाए, जो कैश को गर्म कर देगा। मोटे तौर पर कहें तो हमारी शर्त है कि हमें मास्टर से 10 सेकंड से ज्यादा पीछे नहीं रहना होगा। और यह स्थिति एक लहर में शामिल नहीं है, बल्कि कुछ ग्राहकों के लिए सुचारू रूप से शामिल है।

हां, वज़न बढ़ाएं.

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

Nginx के पास यह विकल्प है slowly start सर्वर के लिए क्लस्टर में। और वह धीरे-धीरे भार बढ़ाता है।

हां, बढ़िया विचार है, जब हम इस तक पहुंच जाएंगे तो हम इसे आजमाएंगे।

स्रोत: www.habr.com