ओडिसी रोडमॅप: कनेक्शन पूलरकडून आम्हाला आणखी काय हवे आहे. आंद्रे बोरोडिन (२०१९)

त्याच्या अहवालात, आंद्रे बोरोडिन तुम्हाला सांगतील की त्यांनी कनेक्शन पूलर डिझाइन करताना PgBouncer स्केलिंग करण्याचा अनुभव कसा विचारात घेतला. ओडिसी, त्यांनी ते उत्पादनात आणले. याव्यतिरिक्त, आम्ही नवीन आवृत्त्यांमध्ये पुलरची कोणती कार्ये पाहू इच्छितो यावर चर्चा करू: आमच्यासाठी केवळ आमच्या गरजा पूर्ण करणेच नाही तर वापरकर्ता समुदाय विकसित करणे देखील महत्त्वाचे आहे. ओडिसी.

व्हिडिओ:

सर्वांना नमस्कार! माझे नाव अँड्र्यू आहे.

Yandex वर, मी मुक्त स्रोत डेटाबेस विकसित करतो. आणि आज आपल्याकडे कनेक्शन पूलर कनेक्शन बद्दल एक विषय आहे.

जर तुम्हाला रशियनमध्ये कनेक्शन पूलर कसे कॉल करावे हे माहित असेल तर मला सांगा. मला खरोखर एक चांगली तांत्रिक संज्ञा शोधायची आहे जी तांत्रिक साहित्यात स्थापित केली पाहिजे.

हा विषय खूपच गुंतागुंतीचा आहे, कारण अनेक डेटाबेसमध्ये कनेक्शन पूलर अंगभूत आहे आणि आपल्याला त्याबद्दल माहित असणे देखील आवश्यक नाही. अर्थात, सर्वत्र काही सेटिंग्ज आहेत, परंतु पोस्टग्रेसमध्ये ते तसे कार्य करत नाही. आणि समांतर (HighLoad++ 2019 वर) Postgres मध्ये क्वेरी सेट करण्याबद्दल निकोलाई समोखवालोव्हचा अहवाल आहे. आणि जसे मला समजले आहे, असे लोक येथे आले आहेत ज्यांनी आधीच त्यांच्या क्वेरी पूर्णपणे कॉन्फिगर केल्या आहेत आणि हे असे लोक आहेत ज्यांना नेटवर्क आणि संसाधनांच्या वापराशी संबंधित अधिक दुर्मिळ सिस्टम समस्यांचा सामना करावा लागतो. आणि काही ठिकाणी समस्या स्पष्ट नसल्याच्या अर्थाने हे खूप कठीण असू शकते.

यांडेक्समध्ये पोस्टग्रेस आहे. Yandex.Cloud मध्ये अनेक Yandex सेवा राहतात. आणि आमच्याकडे अनेक पेटाबाइट डेटा आहे जो पोस्टग्रेसमध्ये प्रति सेकंद किमान एक दशलक्ष विनंत्या निर्माण करतो.

आणि आम्ही सर्व सेवांसाठी बर्‍यापैकी मानक क्लस्टर प्रदान करतो - हा नोडचा मुख्य प्राथमिक नोड आहे, नेहमीच्या दोन प्रतिकृती (सिंक्रोनस आणि असिंक्रोनस), बॅकअप, प्रतिकृतीवरील वाचन विनंत्यांचे स्केलिंग.

प्रत्येक क्लस्टर नोड पोस्टग्रेस आहे, ज्यावर पोस्टग्रेस आणि मॉनिटरिंग सिस्टम व्यतिरिक्त, कनेक्शन पूलर देखील स्थापित केले आहे. कनेक्शन पूलरचा वापर कुंपण घालण्यासाठी आणि त्याच्या मुख्य हेतूसाठी केला जातो.

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

डेटाबेससह काम करताना पोस्टग्रेस एक प्रक्रिया मॉडेल स्वीकारते. याचा अर्थ एक कनेक्शन म्हणजे एक प्रक्रिया, एक पोस्टग्रेस बॅकएंड. आणि या बॅकएंडमध्ये बरेच भिन्न कॅशे आहेत, जे वेगवेगळ्या कनेक्शनसाठी वेगळे करणे खूप महाग आहेत.

याव्यतिरिक्त, Postgres कोडमध्ये procArray नावाचा अ‍ॅरे असतो. यात नेटवर्क कनेक्शनबद्दल मूलभूत डेटा आहे. आणि जवळजवळ सर्व procArray प्रक्रिया अल्गोरिदममध्ये रेखीय जटिलता असते; ते नेटवर्क कनेक्शनच्या संपूर्ण अॅरेवर चालतात. हे एक द्रुत चक्र आहे, परंतु अधिक इनकमिंग नेटवर्क कनेक्शनसह गोष्टी थोड्या अधिक महाग होतात. आणि जेव्हा गोष्टी थोड्या अधिक महाग होतात, तेव्हा तुम्ही बर्‍याच नेटवर्क कनेक्शनसाठी खूप जास्त किंमत मोजू शकता.

3 संभाव्य पद्धती आहेत:

• अर्जाच्या बाजूने.
• डेटाबेस बाजूला.
• आणि दरम्यान, म्हणजे, सर्व प्रकारचे संयोजन.

दुर्दैवाने, बिल्ट-इन पूलर सध्या विकसित होत आहे. PostgreSQL Professional मधील आमचे मित्र हे बहुतांशी करतात. तो कधी दिसेल हे सांगणे कठीण आहे. आणि खरं तर, आमच्याकडे वास्तुविशारदाने निवडण्यासाठी दोन उपाय आहेत. हे ऍप्लिकेशन-साइड पूल आणि प्रॉक्सी पूल आहेत.

ऍप्लिकेशन-साइड पूल हा सर्वात सोपा मार्ग आहे. आणि जवळजवळ सर्व क्लायंट ड्रायव्हर्स तुम्हाला एक मार्ग देतात: कोडमध्ये तुमची लाखो कनेक्शन डेटाबेसमध्ये अनेक डझन कनेक्शन म्हणून सादर करतात.

उद्भवणारी समस्या अशी आहे की एका विशिष्ट टप्प्यावर तुम्हाला बॅकएंड स्केल करायचे आहे, तुम्हाला ते अनेक आभासी मशीन्सवर तैनात करायचे आहे.

मग तुमच्या लक्षात येईल की तुमच्याकडे आणखी अनेक उपलब्धता झोन आहेत, अनेक डेटा सेंटर आहेत. आणि क्लायंट साइड पूलिंग दृष्टीकोन मोठ्या संख्येने ठरतो. मोठे सुमारे 10 कनेक्शन आहेत. ही धार आहे जी सामान्यपणे कार्य करू शकते.

जर आपण प्रॉक्सी पूलर्सबद्दल बोललो तर असे दोन पूलर आहेत जे बरेच काही करू शकतात. ते केवळ पूल करणारे नाहीत. ते पूलर्स + अधिक थंड कार्यक्षमता आहेत. या Pgpool и कुरकुरीत-प्रॉक्सी.

परंतु, दुर्दैवाने, प्रत्येकाला या अतिरिक्त कार्यक्षमतेची आवश्यकता नाही. आणि हे या वस्तुस्थितीकडे नेत आहे की पूलर्स केवळ सत्र पूलिंगला समर्थन देतात, म्हणजे एक येणारा क्लायंट, डेटाबेसला जाणारा एक क्लायंट.

हे आमच्या उद्देशांसाठी फारसे योग्य नाही, म्हणून आम्ही PgBouncer वापरतो, जे व्यवहार पूलिंग लागू करते, म्हणजे सर्व्हर कनेक्शन केवळ व्यवहाराच्या कालावधीसाठी क्लायंट कनेक्शनशी जुळतात.

आणि आमच्या वर्कलोडमध्ये, हे खरे आहे. पण काही समस्या आहेत.

जेव्हा तुम्हाला सत्राचे निदान करायचे असते तेव्हा समस्या सुरू होतात, कारण तुमचे सर्व येणारे कनेक्शन स्थानिक असतात. प्रत्येकजण लूपबॅक घेऊन आला आणि कसा तरी सत्र शोधणे कठीण होते.

अर्थात तुम्ही application_name_add_host वापरू शकता. application_name मध्ये IP पत्ता जोडण्याचा हा बाउन्सर बाजूचा मार्ग आहे. परंतु application_name अतिरिक्त कनेक्शनद्वारे सेट केले आहे.

या आलेखावर, जिथे पिवळी रेषा ही रिअल रिक्वेस्ट आहे आणि जिथे निळी रेषा ही डेटाबेसमध्ये जाणाऱ्या रिक्वेस्ट आहे. आणि हा फरक तंतोतंत application_name च्या स्थापनेचा आहे, जो फक्त ट्रेसिंगसाठी आवश्यक आहे, परंतु तो अजिबात विनामूल्य नाही.

याव्यतिरिक्त, बाउंसरमध्ये तुम्ही एक पूल मर्यादित करू शकत नाही, म्हणजे प्रत्येक विशिष्ट वापरकर्त्यासाठी, विशिष्ट डेटाबेससाठी डेटाबेस कनेक्शनची संख्या.

यातून काय घडते? तुमच्याकडे C++ मध्ये लिहिलेली लोड केलेली सेवा आहे आणि जवळपास कुठेतरी नोडवर एक छोटी सेवा आहे जी डेटाबेससह काहीही भयंकर करत नाही, परंतु तिचा ड्रायव्हर वेडा होतो. हे 20 कनेक्शन उघडते आणि बाकी सर्व काही प्रतीक्षा करेल. तुमचा कोड देखील सामान्य आहे.

आम्ही अर्थातच, बाउन्सरसाठी एक छोटा पॅच लिहिला ज्याने ही सेटिंग जोडली, म्हणजे क्लायंटला पूलमध्ये मर्यादित करणे.

पोस्टग्रेस बाजूने हे करणे शक्य होईल, म्हणजे, कनेक्शनच्या संख्येनुसार डेटाबेसमधील भूमिका मर्यादित करा.

परंतु नंतर आपण सर्व्हरशी कनेक्शन का नाही हे समजून घेण्याची क्षमता गमावता. PgBouncer कनेक्शन त्रुटी फेकत नाही, तो नेहमी समान माहिती परत करतो. आणि तुम्ही समजू शकत नाही: कदाचित तुमचा पासवर्ड बदलला असेल, कदाचित डेटाबेस नुकताच हरवला असेल, कदाचित काहीतरी चूक झाली असेल. पण निदान होत नाही. जर एखादे सत्र स्थापित केले जाऊ शकत नसेल, तर ते का स्थापित केले जाऊ शकत नाही हे तुम्हाला कळणार नाही.

एका विशिष्ट टप्प्यावर, आपण अनुप्रयोग आलेख पहा आणि अनुप्रयोग कार्य करत नसल्याचे पहा.

शीर्षस्थानी पहा आणि बाउन्सर सिंगल-थ्रेडेड असल्याचे पहा. सेवेच्या जीवनातील हा एक टर्निंग पॉइंट आहे. तुमच्या लक्षात आले की तुम्ही दीड वर्षात डेटाबेस स्केल करण्याची तयारी करत आहात आणि तुम्हाला पूलर स्केल करणे आवश्यक आहे.

आम्‍ही या निष्कर्षाप्रत आलो आहोत की आम्हाला आणखी PgBouncers ची गरज आहे.

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

बाउन्सरला थोडा पॅच केला गेला आहे.

आणि त्यांनी ते केले जेणेकरून TCP पोर्टचा पुनर्वापर करून अनेक बाउन्सर उभे केले जाऊ शकतील. आणि ऑपरेटिंग सिस्टीम राऊंड-रॉबिन वापरून इनकमिंग TCP कनेक्शन्स आपोआप ट्रान्सफर करते.

हे क्लायंटसाठी पारदर्शक आहे, याचा अर्थ असे दिसते की तुमच्याकडे एक बाउन्सर आहे, परंतु तुमच्याकडे चालू असलेल्या बाउन्सरमधील निष्क्रिय कनेक्शनचे विभाजन आहे.

आणि एका विशिष्ट क्षणी तुमच्या लक्षात येईल की हे 3 बाउंसर प्रत्येकाने त्यांचा गाभा 100% खाऊन टाकला आहे. तुम्हाला काही बाऊन्सर्सची गरज आहे. का?

कारण तुमच्याकडे TLS आहे. तुमच्याकडे एनक्रिप्टेड कनेक्शन आहे. आणि जर तुम्ही TLS सह आणि त्याशिवाय Postgres बेंचमार्क केले, तर तुम्हाला आढळेल की एनक्रिप्शन सक्षम असलेल्या स्थापित कनेक्शनची संख्या जवळजवळ दोन ऑर्डरने कमी होते, कारण TLS हँडशेक CPU संसाधने वापरते.

आणि शीर्षस्थानी आपण काही क्रिप्टोग्राफिक फंक्शन्स पाहू शकता जे इनकमिंग कनेक्शनची लाट असताना कार्यान्वित केले जातात. आमची प्राथमिक उपलब्धता झोन दरम्यान स्विच करू शकत असल्याने, इनकमिंग कनेक्शनची लहर ही एक सामान्य परिस्थिती आहे. म्हणजेच, काही कारणास्तव जुने प्राथमिक अनुपलब्ध होते, संपूर्ण भार दुसर्या डेटा सेंटरवर पाठविला गेला. ते सर्व एकाच वेळी TLS ला नमस्कार करायला येतील.

आणि मोठ्या संख्येने TLS हँडशेक यापुढे बाउन्सरला हॅलो म्हणणार नाहीत, परंतु त्याचा गळा दाबतील. कालबाह्य झाल्यामुळे, येणार्‍या कनेक्शनची लाट विस्कळीत होऊ शकते. तुम्ही घातांकीय बॅकऑफशिवाय बेसवर पुन्हा प्रयत्न केल्यास, ते सुसंगत लहरीमध्ये पुन्हा पुन्हा येणार नाहीत.

येथे 16 PgBouncers चे उदाहरण आहे जे 16% वर 100 कोर लोड करतात.

आम्ही कॅस्केड PgBouncer वर आलो. हे सर्वोत्कृष्ट कॉन्फिगरेशन आहे जे आमच्या लोडवर बाउन्सरसह साध्य करता येते. आमचे बाह्य बाउंसर TCP हँडशेकसाठी वापरले जातात आणि अंतर्गत बाउन्सर वास्तविक पूलिंगसाठी वापरले जातात, जेणेकरून बाह्य कनेक्शनचे तुकडे जास्त होऊ नयेत.

या कॉन्फिगरेशनमध्ये, एक गुळगुळीत रीस्टार्ट शक्य आहे. तुम्ही हे सर्व 18 बाऊन्सर एक एक करून रीस्टार्ट करू शकता. परंतु असे कॉन्फिगरेशन राखणे खूप कठीण आहे. Sysadmins, DevOps, आणि जे लोक या सर्व्हरसाठी प्रत्यक्षात जबाबदार आहेत त्यांना या व्यवस्थेमुळे फार आनंद होणार नाही.

असे दिसते की आमच्या सर्व सुधारणा ओपन सोर्समध्ये प्रमोट केल्या जाऊ शकतात, परंतु बाउन्सरला फारसे समर्थन नाही. उदाहरणार्थ, एका पोर्टवर अनेक PgBouncers चालवण्याची क्षमता एका महिन्यापूर्वी बांधली गेली होती. अनेक वर्षांपूर्वी या वैशिष्ट्यासह एक पुल विनंती होती.

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

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

किंवा आणखी एक उदाहरण. Postgres मध्ये, तुम्ही अनावश्यक प्रमाणीकरणाशिवाय वेगळ्या कनेक्शनला गुप्त पाठवून प्रगतीपथावर असलेली विनंती रद्द करू शकता. परंतु काही क्लायंट फक्त TCP रीसेट पाठवतात, म्हणजे ते नेटवर्क कनेक्शन खंडित करतात. बाउन्सर काय करेल? तो काही करणार नाही. ती विनंती कार्यान्वित करणे सुरू ठेवेल. जर तुम्हाला मोठ्या संख्येने कनेक्शन मिळाले असतील ज्यांनी लहान विनंत्यांसह डेटाबेस तयार केला असेल, तर फक्त बाउन्सरवरून कनेक्शन डिस्कनेक्ट करणे पुरेसे नाही; तुम्हाला डेटाबेसमध्ये चालू असलेल्या विनंत्या पूर्ण करणे देखील आवश्यक आहे.

हे पॅच केले गेले आहे आणि ही समस्या अद्याप बाउन्सरच्या अपस्ट्रीममध्ये विलीन झालेली नाही.

आणि म्हणून आम्ही या निष्कर्षावर पोहोचलो की आम्हाला आमच्या स्वत: च्या कनेक्शन पूलरची आवश्यकता आहे, जे विकसित केले जाईल, पॅच केले जाईल, ज्यामध्ये समस्या त्वरीत दुरुस्त केल्या जाऊ शकतात आणि जे अर्थातच बहु-थ्रेड केलेले असणे आवश्यक आहे.

आम्ही मुख्य कार्य म्हणून मल्टीथ्रेडिंग सेट करतो. आम्ही येणार्‍या TLS कनेक्शनची लहर चांगल्या प्रकारे हाताळण्यास सक्षम असणे आवश्यक आहे.

हे करण्यासाठी, आम्हाला Machinarium नावाची एक वेगळी लायब्ररी विकसित करावी लागली, जी नेटवर्क कनेक्शनच्या मशीन स्थितीचे अनुक्रमिक कोड म्हणून वर्णन करण्यासाठी डिझाइन केलेली आहे. तुम्ही libpq सोर्स कोड पाहिल्यास, तुम्हाला काही अतिशय क्लिष्ट कॉल्स दिसतील जे तुम्हाला परिणाम देऊ शकतात आणि म्हणतील, “मला नंतर कॉल करा. सध्या माझ्याकडे सध्या IO आहे, पण जेव्हा IO निघून जाईल तेव्हा माझ्याकडे प्रोसेसरचा भार असेल.” आणि ही एक बहु-स्तरीय योजना आहे. नेटवर्क कम्युनिकेशन सहसा स्टेट मशीनद्वारे वर्णन केले जाते. "मला पूर्वी N आकाराचे पॅकेट शीर्षलेख मिळाले असल्यास, आता मी N बाइट्सची वाट पाहत आहे," "मी SYNC पॅकेट पाठवले असल्यास, आता मी परिणाम मेटाडेटा असलेल्या पॅकेटची वाट पाहत आहे" असे बरेच नियम आहेत. परिणाम एक ऐवजी कठीण, काउंटरइंटुटिव्ह कोड आहे, जसे की चक्रव्यूह रेखा स्कॅनमध्ये रूपांतरित झाला आहे. आम्ही ते केले जेणेकरून राज्य मशीनऐवजी, प्रोग्रामर सामान्य अनिवार्य कोडच्या रूपात परस्परसंवादाच्या मुख्य मार्गाचे वर्णन करतो. हे इतकेच आहे की या अत्यावश्यक कोडमध्ये तुम्हाला नेटवर्कवरील डेटाची प्रतीक्षा करून, अंमलबजावणीचा संदर्भ दुसर्‍या कॉरोटिन (ग्रीन थ्रेड) वर पाठवून अंमलबजावणीचा क्रम व्यत्यय आणण्याची आवश्यकता असलेली ठिकाणे समाविष्ट करणे आवश्यक आहे. हा दृष्टिकोन या वस्तुस्थितीसारखाच आहे की आम्ही चक्रव्यूहातील सर्वात अपेक्षित मार्ग एका ओळीत लिहितो आणि नंतर त्यात शाखा जोडतो.

परिणामी, आमच्याकडे एक धागा आहे जो TCP स्वीकारतो आणि राउंड-रॉबिन अनेक कामगारांना TPC कनेक्शन पास करतो.

या प्रकरणात, प्रत्येक क्लायंट कनेक्शन नेहमी एका प्रोसेसरवर चालते. आणि हे आपल्याला कॅशे-अनुकूल बनविण्यास अनुमती देते.

आणि या व्यतिरिक्त, सिस्टम TCP स्टॅकपासून मुक्त होण्यासाठी आम्ही एका मोठ्या पॅकेटमध्ये लहान पॅकेट्सचे संकलन किंचित सुधारले आहे.

याव्यतिरिक्त, आम्ही व्यवहार पूलिंगमध्ये सुधारणा केली आहे की ओडिसी, कॉन्फिगर केल्यावर, नेटवर्क कनेक्शन अयशस्वी झाल्यास रद्द आणि रोलबॅक पाठवू शकते, म्हणजे जर कोणी विनंतीची वाट पाहत नसेल, तर ओडिसी डेटाबेसला प्रयत्न करू नका असे सांगेल. विनंती पूर्ण करा ज्यामुळे मौल्यवान संसाधने वाया जाऊ शकतात.

आणि जेव्हा शक्य असेल तेव्हा आम्ही त्याच क्लायंटशी कनेक्शन ठेवतो. हे application_name_add_host पुन्हा स्थापित करणे टाळते. हे शक्य असल्यास, आम्हाला निदानासाठी आवश्यक असलेले पॅरामीटर्स अतिरिक्तपणे रीसेट करण्याची आवश्यकता नाही.

आम्ही Yandex.Cloud च्या हितासाठी कार्य करतो. आणि जर तुम्ही व्यवस्थापित केलेले PostgreSQL वापरत असाल आणि कनेक्शन पूलर स्थापित केले असेल, तर तुम्ही तार्किक प्रतिकृती वापरून बाहेरून तार्किक प्रतिकृती तयार करू शकता, म्हणजे, तुम्हाला हवे असल्यास, आम्हाला सोडा. बाउंसर तार्किक प्रतिकृती प्रवाह बाहेर सोडणार नाही.

तार्किक प्रतिकृती सेट करण्याचे हे एक उदाहरण आहे.

याव्यतिरिक्त, आम्हाला बाह्य प्रतिकृतीसाठी समर्थन आहे. क्लाउडमध्ये, अर्थातच, हे अशक्य आहे, कारण नंतर क्लस्टर आपल्याला स्वतःबद्दल खूप माहिती देईल. परंतु तुमच्या इंस्टॉलेशन्समध्ये, तुम्हाला ओडिसीमधील कनेक्शन पूलरद्वारे भौतिक प्रतिकृती आवश्यक असल्यास, हे शक्य आहे.

Odyssey मध्ये 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 ओळी आहेत.

ओडिसी आर्किटेक्चर. एक मुख्य मशीन आहे ज्यावर कोरटीन चालू आहेत. हे मशीन इनकमिंग टीसीपी कनेक्शन स्वीकारते आणि कामगारांमध्ये वितरित करते.

अनेक क्लायंटसाठी एक हँडलर एका कामगारामध्ये काम करू शकतो. मुख्य थ्रेड कन्सोल चालवतो आणि पूलमध्ये यापुढे आवश्यक नसलेली कनेक्शन हटविण्यासाठी क्रोन टास्कची प्रक्रिया देखील करतो.

ओडिसीची चाचणी मानक पोस्टग्रेस चाचणी संच वापरून केली जाते. आम्ही फक्त बाउन्सर आणि ओडिसी द्वारे इन्स्टॉल-चेक चालवतो, आम्हाला एक शून्य div मिळते. डेट फॉरमॅटिंगशी संबंधित अनेक चाचण्या आहेत ज्या बाउन्सर आणि ओडिसीमध्ये सारख्याच उत्तीर्ण होत नाहीत.

याव्यतिरिक्त, असे बरेच ड्रायव्हर्स आहेत ज्यांची स्वतःची चाचणी आहे. आणि आम्ही ओडिसीची चाचणी घेण्यासाठी त्यांच्या चाचण्या वापरतो.

याशिवाय, आमच्या कॅस्केड कॉन्फिगरेशनमुळे, आम्हाला विविध बंडलची चाचणी घ्यावी लागेल: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey हे सुनिश्चित करण्यासाठी की ओडिसी कॅस्केडमधील कोणत्याही भागांमध्ये संपला असेल तर ते अजूनही कार्य करते. आम्ही अपेक्षेप्रमाणे.

रॅक

आम्ही उत्पादनात ओडिसी वापरतो. आणि मी असे म्हटले तर ते योग्य होणार नाही की सर्वकाही कार्य करते. नाही, म्हणजे, होय, परंतु नेहमीच नाही. उदाहरणार्थ, प्रॉडक्शनमध्ये सर्वकाही नुकतेच चालले, नंतर पोस्टग्रेएसक्यूएल प्रोफेशनलचे आमचे मित्र आले आणि म्हणाले की आमच्याकडे मेमरी लीक झाली आहे. ते खरोखरच होते, आम्ही त्यांना दुरुस्त केले. पण ते साधे होते.

मग आम्हाला आढळले की कनेक्शन पूलरमध्ये इनकमिंग TLS कनेक्शन आणि आउटगोइंग TLS कनेक्शन आहेत. आणि कनेक्शनसाठी क्लायंट प्रमाणपत्रे आणि सर्व्हर प्रमाणपत्रे आवश्यक आहेत.

बाउंसर आणि ओडिसी सर्व्हर प्रमाणपत्रे त्यांच्या pcache द्वारे पुन्हा वाचली जातात, परंतु क्लायंट प्रमाणपत्रे pcache वरून पुन्हा वाचण्याची आवश्यकता नाही, कारण आमची स्केलेबल Odyssey शेवटी हे प्रमाणपत्र वाचण्याच्या सिस्टम कार्यप्रदर्शनात चालते. हे आमच्यासाठी आश्चर्यचकित झाले, कारण त्याला प्रतिकार करण्यास जास्त वेळ लागला नाही. सुरुवातीला ते रेषीयरित्या मोजले गेले, परंतु 20 इनकमिंग एकाचवेळी कनेक्शननंतर ही समस्या स्वतःच दिसून आली.

प्लग करण्यायोग्य प्रमाणीकरण पद्धत ही अंगभूत Lunux साधने वापरून प्रमाणीकरण करण्याची क्षमता आहे. PgBouncer मध्ये हे अशा प्रकारे लागू केले जाते की PAM कडून प्रतिसादाची प्रतीक्षा करण्यासाठी एक वेगळा थ्रेड आहे आणि एक मुख्य PgBouncer थ्रेड आहे जो वर्तमान कनेक्शनची सेवा देतो आणि त्यांना PAM थ्रेडमध्ये राहण्यास सांगू शकतो.

एका साध्या कारणासाठी आम्ही याची अंमलबजावणी केली नाही. आमच्याकडे बरेच धागे आहेत. आम्हाला याची गरज का आहे?

यामुळे शेवटी समस्या निर्माण होऊ शकतात की जर तुमच्याकडे PAM प्रमाणीकरण आणि नॉन-PAM प्रमाणीकरण असेल, तर PAM प्रमाणीकरणाची मोठी लहर नॉन-PAM प्रमाणीकरणास लक्षणीय विलंब करू शकते. ही त्या गोष्टींपैकी एक आहे जी आम्ही निश्चित केलेली नाही. परंतु जर तुम्हाला त्याचे निराकरण करायचे असेल तर तुम्ही हे करू शकता.

आणखी एक रेक असा होता की आमच्याकडे एक धागा आहे जो येणारे सर्व कनेक्शन स्वीकारतो. आणि नंतर ते कामगार पूलमध्ये स्थानांतरित केले जातात, जिथे TLS हँडशेक होईल.

तळ ओळ, जर तुमच्याकडे 20 नेटवर्क कनेक्शनची सुसंगत लहर असेल, तर ते सर्व स्वीकारले जातील. आणि क्लायंटच्या बाजूला libpq टाइमआउट्सचा अहवाल देणे सुरू करेल. डीफॉल्टनुसार ते 000 सेकंद असल्याचे दिसते.

जर ते सर्व एकाच वेळी डेटाबेसमध्ये प्रवेश करू शकत नसतील, तर ते डेटाबेसमध्ये प्रवेश करू शकत नाहीत, कारण हे सर्व नॉन-एक्सपोनेन्शिअल पुन्हा प्रयत्नाद्वारे कव्हर केले जाऊ शकते.

आम्ही या निष्कर्षावर पोहोचलो की आम्ही PgBouncer वरून योजना कॉपी केली आहे की आम्ही स्वीकारलेल्या TCP कनेक्शनची संख्या थ्रॉटलिंग करत आहोत.

जर आम्ही पाहिले की आम्ही कनेक्शन स्वीकारत आहोत, परंतु त्यांना शेवटी हँडशेक करण्यासाठी वेळ नाही, आम्ही त्यांना एका रांगेत उभे करतो जेणेकरून ते CPU संसाधने वाया घालवू नयेत. यामुळे आलेले सर्व कनेक्शन्ससाठी एकाचवेळी हँडशेक केले जाऊ शकत नाही. परंतु लोड जोरदार असला तरीही किमान कोणीतरी डेटाबेसमध्ये प्रवेश करेल.

आराखडा

ओडिसीमध्ये तुम्हाला भविष्यात काय पाहायला आवडेल? आपण स्वत:चा विकास करण्यासाठी काय तयार आहोत आणि समाजाकडून आपण काय अपेक्षा करतो?

ऑगस्ट 2019 पर्यंत.

ऑगस्टमध्ये ओडिसी रोडमॅप असा दिसत होता:

• आम्हाला SCRAM आणि PAM प्रमाणीकरण हवे होते.
• आम्हाला वाचन विनंत्या स्टँडबायवर फॉरवर्ड करायच्या होत्या.
• मला ऑनलाइन रीस्टार्ट करायचे आहे.
• आणि सर्व्हरवर विराम देण्याची क्षमता.

या रोडमॅपचा अर्धा भाग पूर्ण झाला आहे, आमच्याकडून नाही. आणि हे चांगले आहे. तर आता काय उरले आहे यावर चर्चा करूया आणि अजून भर टाकूया.

स्टँडबायसाठी फॉरवर्ड ओन्ली-रीड क्वेरींबाबत? आमच्याकडे अशा प्रतिकृती आहेत ज्या विनंत्या अंमलात आणल्याशिवाय हवा गरम करतील. आम्हाला फेलओव्हर आणि स्विचओव्हर प्रदान करण्यासाठी त्यांची आवश्यकता आहे. एका डेटा सेंटरमध्ये समस्या असल्यास, मी त्यांना काही उपयुक्त कामांसह व्यापू इच्छितो. कारण आम्ही समान सेंट्रल प्रोसेसर, समान मेमरी वेगळ्या पद्धतीने कॉन्फिगर करू शकत नाही, कारण अन्यथा प्रतिकृती कार्य करणार नाही.

तत्त्वानुसार, Postgres मध्ये, 10 पासून सुरू होणारे, कनेक्ट करताना session_attrs निर्दिष्ट करणे शक्य आहे. तुम्ही कनेक्शनमधील सर्व डेटाबेस होस्टची यादी करू शकता आणि तुम्ही डेटाबेसवर का जात आहात हे सांगू शकता: फक्त लिहा किंवा वाचू शकता. आणि ड्रायव्हर स्वतः यादीतील पहिला होस्ट निवडेल जे त्याला सर्वात जास्त आवडते, जे सत्र_attrs च्या आवश्यकता पूर्ण करते.

परंतु या दृष्टिकोनाची समस्या अशी आहे की ते प्रतिकृती अंतर नियंत्रित करत नाही. तुमच्याकडे काही प्रतिकृती असू शकतात जी तुमच्या सेवेसाठी अस्वीकार्य कालावधीसाठी मागे पडली आहेत. प्रतिकृतीवर वाचलेल्या प्रश्नांची पूर्ण-वैशिष्ट्यपूर्ण अंमलबजावणी सक्षम करण्यासाठी, जेव्हा ते वाचले जाऊ शकत नाही तेव्हा आम्हाला ओडिसीच्या कार्यक्षमतेचे समर्थन करणे आवश्यक आहे.

ओडिसीने वेळोवेळी डेटाबेसवर जाणे आवश्यक आहे आणि प्राथमिक पासून प्रतिकृतीचे अंतर विचारले पाहिजे. आणि जर ते मर्यादा मूल्यापर्यंत पोहोचले असेल तर, डेटाबेसमध्ये नवीन विनंत्यांना परवानगी देऊ नका, क्लायंटला सांगा की त्याला कनेक्शन पुन्हा सुरू करण्याची आवश्यकता आहे आणि, शक्यतो, विनंत्या अंमलात आणण्यासाठी दुसरा होस्ट निवडा. हे डेटाबेसला प्रतिकृती अंतर द्रुतपणे पुनर्संचयित करण्यास आणि विनंतीसह प्रतिसाद देण्यासाठी पुन्हा परत येण्यास अनुमती देईल.

अंमलबजावणीसाठी वेळ देणे कठीण आहे, कारण ते मुक्त स्रोत आहे. पण, मला आशा आहे, PgBouncer मधील माझ्या सहकाऱ्यांप्रमाणे 2,5 वर्षे नाही. हे वैशिष्ट्य मला ओडिसीमध्ये पाहायला आवडेल.

समुदायामध्ये, लोकांनी तयार केलेल्या विधानाच्या समर्थनाबद्दल विचारले. आता तुम्ही दोन प्रकारे तयार विधान तयार करू शकता. प्रथम, तुम्ही SQL कमांड कार्यान्वित करू शकता, म्हणजे "तयार". ही SQL कमांड समजून घेण्यासाठी, आम्हाला बाउंसर बाजूचे SQL समजून घेणे शिकले पाहिजे. हे ओव्हरकिल असेल, कारण ते ओव्हरकिल आहे, कारण आम्हाला संपूर्ण पार्सरची आवश्यकता आहे. आम्ही प्रत्येक SQL कमांडचे विश्लेषण करू शकत नाही.

परंतु proto3 वर संदेश प्रोटोकॉल स्तरावर एक तयार विधान आहे. आणि हे असे ठिकाण आहे जेव्हा तयार केलेले विधान तयार केले जात असल्याची माहिती संरचित स्वरूपात येते. आणि काही सर्व्हर कनेक्शनवर क्लायंटने तयार स्टेटमेंट तयार करण्यास सांगितले या समजुतीचे आम्ही समर्थन करू शकतो. आणि व्यवहार बंद असला तरीही, आम्हाला सर्व्हर आणि क्लायंट दरम्यान कनेक्टिव्हिटी राखण्याची आवश्यकता आहे.

परंतु येथे संवादात एक विसंगती उद्भवली आहे, कारण कोणीतरी म्हणते की क्लायंटने कोणत्या प्रकारचे तयार स्टेटमेंट तयार केले आहे हे समजून घेणे आवश्यक आहे आणि हे सर्व्हर कनेक्शन तयार केलेल्या सर्व क्लायंटमध्ये सर्व्हर कनेक्शन सामायिक करणे आवश्यक आहे, म्हणजे, ज्यांनी असे तयार विधान तयार केले आहे.

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

आणि आणखी एक वैशिष्ट्य जे आम्हाला अंमलात आणण्याची गरज आहे. आमच्याकडे आता PgBouncer सह सुसंगत मॉनिटरिंग आहे. आम्ही सरासरी क्वेरी अंमलबजावणी वेळ परत करू शकतो. परंतु सरासरी वेळ रुग्णालयात सरासरी तापमान आहे: काही थंड आहेत, काही उबदार आहेत - सरासरी, प्रत्येकजण निरोगी आहे. हे खरे नाही.

आम्हाला पर्सेंटाइलसाठी समर्थन लागू करणे आवश्यक आहे जे सूचित करेल की संसाधने वाया घालवणार्‍या आणि मॉनिटरिंगला अधिक स्वीकार्य बनवणार्‍या संथ क्वेरी आहेत.

सर्वात महत्त्वाची गोष्ट म्हणजे मला आवृत्ती १.० हवी आहे (आवृत्ती १.१ आधीच प्रसिद्ध झाली आहे). वस्तुस्थिती अशी आहे की ओडिसी आता आवृत्ती 1.0rc मध्ये आहे, म्हणजे रिलीझ उमेदवार. आणि मी सूचीबद्ध केलेल्या सर्व समस्या मेमरी लीक वगळता अगदी त्याच आवृत्तीसह निश्चित केल्या गेल्या.

आवृत्ती 1.0 चा आमच्यासाठी काय अर्थ असेल? आम्ही आमच्या तळांवर ओडिसी आणत आहोत. हे आमच्या डेटाबेसवर आधीपासूनच चालू आहे, परंतु जेव्हा ते 1 विनंत्या प्रति सेकंदापर्यंत पोहोचते, तेव्हा आम्ही असे म्हणू शकतो की ही रिलीझ आवृत्ती आहे आणि ही एक आवृत्ती आहे ज्याला 000 म्हटले जाऊ शकते.

समुदायातील बर्‍याच लोकांनी विचारले आहे की आवृत्ती 1.0 मध्ये विराम आणि SCRAM समाविष्ट आहे. परंतु याचा अर्थ असा होईल की आम्हाला पुढील आवृत्ती उत्पादनासाठी रोल आउट करणे आवश्यक आहे, कारण अद्याप SCRAM किंवा विराम दोन्ही मारले गेले नाहीत. परंतु, बहुधा, ही समस्या खूप लवकर सोडवली जाईल.

मी तुमच्या पुल विनंतीची वाट पाहत आहे. मला हे देखील ऐकायला आवडेल की तुम्हाला बाउन्सरमध्ये कोणत्या समस्या आहेत. त्यांची चर्चा करूया. कदाचित आम्ही तुम्हाला आवश्यक असलेली काही कार्ये अंमलात आणू शकतो.

हा माझ्या भागाचा शेवट आहे, मला तुमचे ऐकायचे आहे. धन्यवाद!

प्रश्न

मी माझे स्वतःचे अर्ज_नाव सेट केल्यास, ते ओडिसीमधील व्यवहार पूलिंगसह योग्यरित्या अग्रेषित केले जाईल का?

ओडिसी की बाउन्सर?

ओडिसी मध्ये. बाउन्सरमध्ये ते फेकले जाते.

आम्ही एक सेट करू.

आणि माझे वास्तविक कनेक्शन इतर कनेक्शनवर उडी मारल्यास, ते प्रसारित केले जाईल का?

आम्ही सूचीमध्ये सूचीबद्ध असलेल्या सर्व पॅरामीटर्सचा एक संच बनवू. अर्ज_नाव या यादीत आहे की नाही हे मी सांगू शकत नाही. मला वाटते की मी त्याला तिथे पाहिले. आम्ही सर्व समान पॅरामीटर्स सेट करू. एका विनंतीसह, सेट स्टार्टअप दरम्यान क्लायंटद्वारे स्थापित केलेल्या सर्व गोष्टी करेल.

धन्यवाद, आंद्रे, अहवालासाठी! चांगला अहवाल! मला आनंद आहे की ओडिसी प्रत्येक मिनिटाला वेगाने आणि वेगाने विकसित होत आहे. मला असेच चालू ठेवायचे आहे. आम्‍ही तुम्‍हाला आधीच मल्‍टी डेटा-स्रोत कनेक्‍शन असण्‍यास सांगितले आहे जेणेकरुन Odyssey एकाच वेळी वेगवेगळ्या डेटाबेसेसशी कनेक्ट होऊ शकेल, म्हणजे एक मास्टर स्लेव्ह, आणि नंतर फेलओव्हरनंतर आपोआप नवीन मास्टरशी कनेक्ट होऊ शकेल.

होय, मला ही चर्चा आठवत आहे. आता अनेक स्टोअर्स आहेत. परंतु त्यांच्यामध्ये कोणतेही स्विचिंग नाही. आमच्या बाजूने, आम्ही सर्व्हरचे सर्वेक्षण केले पाहिजे की तो अद्याप जिवंत आहे आणि समजले पाहिजे की एक फेलओव्हर झाला आहे, जो pg_recovery कॉल करेल. मला समजण्याचा एक मानक मार्ग आहे की आम्ही मास्टरकडे आलो नाही. आणि चुकांमधून कसं तरी समजून घ्यावं की काय? म्हणजेच ही कल्पना रंजक आहे, अशी चर्चा सुरू आहे. अधिक टिप्पण्या लिहा. जर तुमच्याकडे सी माहित असलेले कामगार असतील तर ते छान आहे.

प्रतिकृतींमध्ये स्केलिंग करण्याचा मुद्दा देखील आमच्यासाठी स्वारस्यपूर्ण आहे, कारण आम्ही ऍप्लिकेशन डेव्हलपरसाठी प्रतिकृती क्लस्टर्सचा अवलंब करणे शक्य तितके सोपे बनवू इच्छितो. परंतु येथे मला अधिक टिप्पण्या आवडतील, म्हणजे ते कसे करावे, ते कसे चांगले करावे.

प्रश्न प्रतिकृतींचाही आहे. असे दिसून आले की आपल्याकडे एक मास्टर आणि अनेक प्रतिकृती आहेत. आणि हे स्पष्ट आहे की ते कनेक्शनसाठी मास्टरपेक्षा कमी वेळा प्रतिकृतीकडे जातात, कारण त्यांच्यात मतभेद असू शकतात. तुम्ही म्हणालात की डेटामधला फरक असा असू शकतो की त्यामुळे तुमच्या व्यवसायाचे समाधान होणार नाही आणि त्याची प्रतिकृती तयार होईपर्यंत तुम्ही तिथे जाणार नाही. त्याच वेळी, जर तुम्ही तेथे बराच काळ गेला नाही आणि नंतर जायला लागला तर आवश्यक असलेला डेटा त्वरित उपलब्ध होणार नाही. म्हणजेच, जर आपण सतत मास्टरकडे गेलो तर तेथील कॅशे गरम होईल, परंतु प्रतिकृतीमध्ये कॅशे थोडा मागे पडेल.

हो हे खरे आहे. pcache मध्ये तुम्हाला हवे असलेले डेटा ब्लॉक्स नसतील, खऱ्या कॅशेमध्ये तुम्हाला हव्या असलेल्या टेबल्सची माहिती नसेल, प्लॅनमध्ये पार्स केलेल्या क्वेरी नसतील, काहीही नसेल.

आणि जेव्हा तुमच्याकडे काही प्रकारचा क्लस्टर असतो आणि तुम्ही तिथे एक नवीन प्रतिकृती जोडता, तेव्हा ते सुरू होत असताना, त्यात सर्व काही खराब असते, म्हणजेच ते कॅशे वाढवते.

मला कल्पना आली. योग्य दृष्टीकोन म्हणजे प्रतिकृतीवर प्रथम काही टक्के क्वेरी चालवणे, ज्यामुळे कॅशे गरम होईल. ढोबळपणे बोलायचे झाल्यास, आमची एक अट आहे की आपण मास्टरच्या मागे 10 सेकंदांपेक्षा जास्त नसावे. आणि ही स्थिती एका वेव्हमध्ये समाविष्ट केलेली नाही, परंतु काही क्लायंटसाठी सहजतेने.

होय, वजन वाढवा.

ही एक चांगली कल्पना आहे. पण आधी या बंदची अंमलबजावणी करायला हवी. प्रथम आपल्याला बंद करणे आवश्यक आहे, आणि नंतर आपण कसे चालू करावे याबद्दल विचार करू. सहजतेने सक्षम करण्यासाठी हे एक उत्तम वैशिष्ट्य आहे.

Nginx कडे हा पर्याय आहे slowly start सर्व्हरसाठी क्लस्टरमध्ये. आणि तो हळूहळू भार वाढवतो.

होय, छान कल्पना, आम्ही ते शोधून काढू तेव्हा आम्ही प्रयत्न करू.

स्त्रोत: www.habr.com