ओडिसी रोडम्याप: हामी जडान पूलरबाट अरू के चाहन्छौं। आन्द्रे बोरोडिन (२०१९)

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

भिडियो:

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

Yandex मा, म खुला स्रोत डाटाबेसहरू विकास गर्दैछु। र आज हामीसँग जडान पूलर जडानहरूको बारेमा विषय छ।

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

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

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

र हामी सबै सेवाहरूको लागि एकदम सामान्य क्लस्टर प्रदान गर्दछौं - यो नोडको मुख्य प्राथमिक नोड हो, सामान्य दुई प्रतिकृतिहरू (सिंक्रोनस र एसिन्क्रोनस), ब्याकअप, प्रतिकृतिमा पढ्ने अनुरोधहरूको स्केलिङ।

प्रत्येक क्लस्टर नोड पोस्टग्रेस हो, जसमा, पोस्टग्रेस र निगरानी प्रणालीको अतिरिक्त, जडान पूलर पनि स्थापना गरिएको छ। जडान पूलर फेंसिंग र यसको मुख्य उद्देश्यको लागि प्रयोग गरिन्छ।

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

Postgres डाटाबेस संग काम को लागी एक प्रक्रिया मोडेल अपनाउछ। यसको मतलब एक जडान एक प्रक्रिया हो, एक Postgres ब्याकएन्ड। र यस ब्याकइन्डमा धेरै फरक क्यासहरू छन्, जुन विभिन्न जडानहरूको लागि फरक बनाउन धेरै महँगो छ।

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

त्यहाँ 3 सम्भावित दृष्टिकोणहरू छन्:

• आवेदन पक्षमा।
• डाटाबेस पक्षमा।
• र बीचमा, त्यो हो, सबै सम्भावित संयोजनहरू।

दुर्भाग्यवश, बिल्ट-इन पूलर हाल विकास अन्तर्गत छ। PostgreSQL प्रोफेशनलका साथीहरूले यो प्रायः गर्छन्। यो कहिले देखा पर्नेछ भविष्यवाणी गर्न गाह्रो छ। र वास्तवमा, हामीसँग वास्तुकारको छनौटको लागि दुई समाधानहरू छन्। यी एप्लिकेसन-साइड पूल र प्रोक्सी पूल हुन्।

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

त्यहाँ समस्या छ कि कुनै बिन्दुमा तपाइँ ब्याकइन्ड मापन गर्न चाहानुहुन्छ, तपाइँ यसलाई धेरै भर्चुअल मेसिनहरूमा तैनात गर्न चाहनुहुन्छ।

त्यसोभए तपाईंले अझै पनि महसुस गर्नुहुन्छ कि तपाईंसँग धेरै उपलब्धता क्षेत्रहरू छन्, धेरै डाटा केन्द्रहरू। र ग्राहक पक्ष पूलिङ दृष्टिकोणले ठूलो संख्यामा पुग्छ। ठूलाहरू करिब १०,००० जडानहरू छन्। यो एक किनारा हो जसले राम्रो काम गर्न सक्छ।

यदि हामी प्रोक्सी पूलरहरूको बारेमा कुरा गर्छौं भने, त्यहाँ दुईवटा पूलरहरू छन् जसले धेरै चीजहरू गर्न सक्छन्। तिनीहरू पोलर मात्र होइनन्। तिनीहरू पूलरहरू + अधिक राम्रो कार्यक्षमता हुन्। यो 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 सँग र बिना पोस्टग्रेसलाई बेन्चमार्क गर्नुभयो भने, तपाईंले एन्क्रिप्शन सक्षम भएकोमा स्थापित जडानहरूको संख्या लगभग दुई अर्डरले घटेको पाउनुहुनेछ, किनभने TLS ह्यान्डशेकले CPU स्रोतहरू खपत गर्दछ।

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

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

यहाँ 16 PgBouncers को एक उदाहरण छ जुन 16 कोर 100% मा लोड हुन्छ।

हामी क्यास्केडिङ PgBouncer मा आइपुगेका छौं। यो हामीले हाम्रो बाउन्सर लोडमा प्राप्त गर्न सक्ने उत्तम कन्फिगरेसन हो। हाम्रा बाह्य बाउन्सरहरूले TCP ह्यान्डशेकका लागि सेवा गर्छन्, र आन्तरिक बाउन्सरहरूले बाह्य जडानहरूलाई ठूलो मात्रामा टुक्राउन नदिने गरी वास्तविक पूलिङका लागि सेवा गर्छन्।

यो कन्फिगरेसनमा, नरम पुन: सुरु गर्न सम्भव छ। तपाइँ यी सबै 18 बाउन्सरहरू एक एक गरेर पुन: सुरु गर्न सक्नुहुन्छ। तर यस्तो कन्फिगरेसन कायम राख्न धेरै गाह्रो छ। प्रणाली प्रशासकहरू, 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 स्ट्याक अफलोड गर्नका लागि सानो प्याकेटहरूको सङ्कलनलाई एउटा ठूलो प्याकेटमा अलिकति सुधार गरेका छौं।

थप रूपमा, हामीले लेनदेन पूलिङमा सुधार गरेका छौं कि Odyssey, जब कन्फिगर गरिएको छ, नेटवर्क जडान विफलताको अवस्थामा रद्द र ROLLBACK पठाउन सक्छ, अर्थात् यदि कसैले अनुरोधको लागि पर्खिरहेको छैन भने, Odyssey ले डाटाबेसलाई पूरा गर्न प्रयास नगर्न बताउनेछ। अनुरोध जसले बहुमूल्य स्रोतहरू बर्बाद गर्न सक्छ।

र सम्भव भएसम्म, हामी एउटै ग्राहकसँग जडान राख्छौं। यसले 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 मानक सन्देशहरू हो जुन फ्रन्टएन्डहरू र ब्याकएन्डहरूले आदानप्रदान गर्न सक्छन्। तिनीहरू किवी पुस्तकालयमा लागू हुन्छन्।

Machinarium पुस्तकालय एक थ्रेड कार्यान्वयन पुस्तकालय हो। यस मेसिनेरियमको सानो टुक्रा एसेम्बलरमा लेखिएको छ। तर चिन्ता नगर्नुहोस्, त्यहाँ केवल 15 लाइनहरू छन्।

ओडिसी वास्तुकला। त्यहाँ एउटा मुख्य मेसिन चलिरहेको कोरटिनहरू छ। यो मेसिनले आगमन TCP जडानहरू स्वीकार गर्ने र कामदारहरू बीच वितरण गर्ने कार्यहरू लागू गर्दछ।

एक कार्यकर्ता भित्र, धेरै ग्राहकहरूको लागि ह्यान्डलरले काम गर्न सक्छ। र मुख्य थ्रेडमा पनि, पूलमा आवश्यक नपर्ने जडानहरू हटाउनको लागि कन्सोल र क्रोन कार्यहरूको प्रशोधन कताई रहेको छ।

Odyssey मानक Postgres परीक्षण सुइट प्रयोग गरेर परीक्षण गरिएको छ। हामी केवल बाउन्सर मार्फत र ओडिसी मार्फत स्थापना-चेक चलाउँछौं, हामीले एक नल डिभ पाउँछौं। त्यहाँ मिति ढाँचासँग सम्बन्धित धेरै परीक्षणहरू छन् जुन बाउन्सर र ओडिसीमा ठ्याक्कै उस्तै असफल हुन्छन्।

थप रूपमा, त्यहाँ धेरै चालकहरू छन् जसको आफ्नै परीक्षण छ। र हामी ओडिसी परीक्षण गर्न तिनीहरूको परीक्षण प्रयोग गर्छौं।

साथै, हाम्रो क्यास्केडिङ कन्फिगरेसनको कारणले, हामीले विभिन्न बन्डलहरू परीक्षण गर्नुपर्छ: Postgres + Odyssey, PgBouncer + Odyssey, Odyssey + Odyssey यदि ओडिसी क्यास्केडको कुनै पनि भागमा छ भने, यसले अझै पनि अपेक्षित रूपमा काम गर्छ। ।

रेक

हामी उत्पादनमा ओडिसी प्रयोग गर्छौं। र यो उचित हुनेछैन यदि मैले भनेको सबै कुरा मात्र काम गर्दछ। होइन, अर्थात् हो, तर सधैं होइन। उदाहरणका लागि, उत्पादनमा सबै कुराले भर्खरै काम गर्यो, त्यसपछि PostgreSQL Professional बाट हाम्रा साथीहरू आए र भने कि हामीसँग मेमोरी लीक छ। तिनीहरू वास्तवमै थिए, हामीले तिनीहरूलाई ठीक गर्यौं। तर यो सरल थियो।

त्यसपछि हामीले जडान पूलरमा आगमन TLS जडानहरू र बाहिर जाने TLS जडानहरू छन् भनेर फेला पार्यौं। र जडानहरूलाई ग्राहक प्रमाणपत्रहरू र सर्भर प्रमाणपत्रहरू चाहिन्छ।

बाउन्सर र ओडिसी सर्भर प्रमाणपत्रहरू pcache द्वारा पुन: पढिन्छ, तर ग्राहक प्रमाणपत्रहरू pcache बाट पुन: पढ्न आवश्यक छैन, किनभने हाम्रो स्केलेबल Odyssey अन्ततः यो प्रमाणपत्र पढ्नको प्रणाली प्रदर्शनमा निर्भर हुन्छ। यो हाम्रो लागि अचम्मको रूपमा आयो, किनभने उहाँले तुरुन्तै आराम गर्नुभएन। सुरुमा यो रैखिक रूपमा मापन गरियो, र 20 आगमन एक साथ जडानहरू पछि, यो समस्या आफैं प्रकट भयो।

प्लगेबल प्रमाणीकरण विधि बिल्ट-इन लुनक्स उपकरणहरूसँग प्रमाणीकरण गर्ने क्षमता हो। PgBouncer मा, यो PAM बाट प्रतिक्रियाको लागि पर्खिरहेको एउटा छुट्टै थ्रेड छ र हालको जडानलाई सेवा गर्ने मुख्य PgBouncer थ्रेड छ र तिनीहरूलाई PAM थ्रेडमा बस्न सोध्न सक्ने गरी कार्यान्वयन गरिएको छ।

हामीले एउटा साधारण कारणले यसलाई कार्यान्वयन गरेका छैनौं। हामीसँग धेरै धाराहरू छन्। हामीलाई किन चाहिन्छ?

नतिजाको रूपमा, यसले समस्याहरू सिर्जना गर्न सक्छ यदि तपाईंसँग PAM प्रमाणीकरण र गैर-PAM प्रमाणीकरण छ भने, PAM प्रमाणीकरणको ठूलो लहरले गैर-PAM प्रमाणीकरणलाई उल्लेखनीय रूपमा ढिलाइ गर्न सक्छ। यो ती चीजहरू मध्ये एक हो जुन हामीले ठीक गरेका छैनौं। तर यदि तपाइँ यसलाई ठीक गर्न चाहनुहुन्छ भने, तपाइँ यो गर्न सक्नुहुन्छ।

अर्को रेक यस तथ्यको साथ थियो कि हामीसँग एउटा थ्रेड छ जसले सबै आगमन जडानहरू स्वीकार गर्दछ। र त्यसपछि तिनीहरूलाई कार्यकर्ता पूलमा स्थानान्तरण गरिन्छ, जहाँ TLS ह्यान्डशेक हुनेछ।

नतिजाको रूपमा, यदि तपाईंसँग 20 नेटवर्क जडानहरूको सुसंगत लहर छ भने, ती सबै स्वीकार गरिनेछन्। र ग्राहक पक्षमा, libpq ले टाइमआउट रिपोर्टिङ सुरु गर्नेछ। पूर्वनिर्धारित रूपमा, यो त्यहाँ 000 सेकेन्ड जस्तै छ।

यदि तिनीहरू सबै एकै समयमा आधारमा प्रवेश गर्न सक्दैनन् भने, तिनीहरू आधारमा प्रवेश गर्न सक्दैनन्, किनभने यो सबै गैर-घातीय पुन: प्रयास द्वारा कभर गर्न सकिन्छ।

हामीले PgBouncer योजना यहाँ प्रतिलिपि गरेर समाप्त गर्यौं ताकि हामीले स्वीकार गर्ने TCP जडानहरूको संख्या थ्रोटल गर्दैछौं।

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

Roadmap

ओडिसीमा भविष्यमा के हेर्न चाहनुहुन्छ? हामी आफैंको विकास गर्न के तयार छौं र हामी समुदायबाट के आशा गर्छौं?

अगस्त 2019 को लागि।

यो अगस्टमा ओडिसी रोडम्याप जस्तो देखिन्छ:

• हामी SCRAM र PAM प्रमाणीकरण चाहन्थ्यौं।
• हामी स्ट्यान्डबाइमा पढ्न अनुरोधहरू फर्वार्ड गर्न चाहन्थ्यौं।
• म अनलाइन पुन: सुरु गर्न चाहन्छु।
• र सर्भरमा पज गर्ने क्षमता।

यो रोडम्यापको आधा हो, हामीले होइन। र यो राम्रो छ। त्यसोभए के बाँकी छ छलफल गरौं र थप थपौं।

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

सिद्धान्तमा, Postgres मा, 10 बाट सुरु, यो जडान गर्दा session_attrs निर्दिष्ट गर्न सम्भव छ। तपाइँ जडानमा सबै डाटाबेस होस्टहरू सूचीबद्ध गर्न सक्नुहुन्छ र तपाइँ किन डाटाबेसमा जाँदै हुनुहुन्छ भन्न सक्नुहुन्छ: लेख्नुहोस् वा पढ्नुहोस्। र ड्राइभर आफैले सूचीमा पहिलो होस्ट छनौट गर्नेछ जुन यसलाई राम्रो मनपर्दछ, जसले सत्र_attrs को आवश्यकताहरू पूरा गर्दछ।

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

ओडिसीले समय समयमा डाटाबेसमा जानुपर्छ र प्राथमिकबाट प्रतिकृति दूरी सोध्नु पर्छ। र यदि यो सीमामा पुग्यो भने, डाटाबेसमा नयाँ अनुरोधहरू नदिनुहोस्, ग्राहकलाई भन्नुहोस् कि तपाइँ जडानहरू पुन: सुरु गर्न आवश्यक छ र, सम्भवतः, अनुरोधहरू कार्यान्वयन गर्न अर्को होस्ट चयन गर्नुहोस्। यसले डाटाबेसलाई प्रतिकृति ढिलाइलाई छिटो पुनर्स्थापना गर्न र क्वेरीको साथ जवाफ दिन फेरि फर्कन अनुमति दिनेछ।

यो कार्यान्वयन मितिहरू नाम गर्न गाह्रो छ, किनभने यो खुला स्रोत हो। तर, मलाई आशा छ, PgBouncer को सहकर्मीहरू जस्तै 2,5 वर्ष होइन। यो ओडिसीमा म हेर्न चाहन्छु।

समुदायमा, मानिसहरूले तयार बयान समर्थनको बारेमा सोधे। अब तपाइँ दुई तरिकामा तयार कथन बनाउन सक्नुहुन्छ। पहिले, तपाइँ SQL आदेश कार्यान्वयन गर्न सक्नुहुन्छ, अर्थात् "तयार"। यो SQL आदेश बुझ्नको लागि, हामीले बाउन्सर साइडमा SQL लाई कसरी बुझ्ने भनेर सिक्नु आवश्यक छ। यो overkill हुनेछ किनभने यो overkill छ किनकि हामीलाई सम्पूर्ण पार्सर चाहिन्छ। हामी प्रत्येक SQL आदेशलाई पार्स गर्न सक्दैनौं।

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

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

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

र एउटा थप सुविधा जुन हामीले कार्यान्वयन गर्न आवश्यक छ। हामीसँग अब PgBouncer सँग उपयुक्त निगरानी छ। हामी औसत क्वेरी कार्यान्वयन समय फर्काउन सक्छौं। तर औसत समय अस्पतालको औसत तापक्रम हो: कोही चिसो छ, कोही न्यानो छ - औसतमा सबैजना स्वस्थ छन्। यो सत्य होइन।

हामीले प्रतिशतका लागि समर्थन लागू गर्न आवश्यक छ, जसले स्रोतहरू खपत गर्ने ढिलो अनुरोधहरू छन् र अनुगमनलाई थप स्वीकार्य बनाउँदछ भनेर संकेत गर्दछ।

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

संस्करण १.० ले हाम्रो लागि के अर्थ राख्छ? हामी ओडिसीलाई हाम्रो आधारहरूमा रोल आउट गर्दैछौं। यो पहिले नै हाम्रो डाटाबेसहरूमा चलिरहेको छ, तर जब यो प्रति सेकेन्ड 1.0 अनुरोधहरूको बिन्दुमा पुग्छ, तब हामी भन्न सक्छौं कि यो रिलीज संस्करण हो र यो एक संस्करण हो जसलाई 1 भन्न सकिन्छ।

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

म तपाईंको पुल अनुरोधको लागि पर्खिरहेको छु। र म यो पनि सुन्न चाहन्छु कि तपाइँ बाउन्सर संग के समस्या छ। तिनीहरूको छलफल गरौं। हुनसक्छ हामी तपाईंलाई आवश्यक पर्ने केही कार्यहरू लागू गर्न सक्छौं।

यो मेरो भाग समाप्त हुन्छ, म तपाईबाट सुन्न चाहन्छु। धन्यवाद!

तपाईंका प्रश्नहरू

यदि मैले मेरो आफ्नै application_name राखें भने, के यो ओडिसीमा लेनदेन पूलिङ सहित सही रूपमा फ्याँकिन्छ?

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

ओडिसी मा। बाउन्सर फ्याँकिएको छ।

हामी एक सेट बनाउँछौं।

र यदि मेरो वास्तविक जडान अन्य जडानहरूमा हप हुन्छ भने, यो प्रसारित हुनेछ?

हामी सूचीबद्ध गरिएका सबै प्यारामिटरहरूको सेट बनाउनेछौं। म भन्न सक्दिन कि application_name यो सूचीमा छ। उसलाई त्यहाँ देखेको जस्तो लाग्छ। हामी सबै समान प्यारामिटरहरू सेट गर्नेछौं। एउटा अनुरोधको साथ, सेटले स्टार्टअपको समयमा ग्राहकद्वारा स्थापित गरेको सबै काम गर्नेछ।

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

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

प्रतिकृतिहरूमा मापन गर्ने मुद्दा हाम्रो लागि पनि चासोको छ, किनकि हामी अनुप्रयोग विकासकर्ताहरूका लागि प्रतिकृति क्लस्टरहरूलाई सकेसम्म सरल बनाउन चाहन्छौं। तर यहाँ म थप टिप्पणीहरू चाहन्छु, त्यो हो, यो कसरी गर्ने, कसरी राम्रो गर्ने।

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

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

र जब तपाईंसँग कुनै प्रकारको क्लस्टर हुन्छ, र तपाईंले त्यहाँ नयाँ प्रतिकृति थप्नुहुन्छ, तब यो सुरु हुँदा, यसमा सबै कुरा खराब हुन्छ, अर्थात् यसले यसको क्यास बढाउँछ।

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

हो, वजन बढाउनुहोस्।

यो एक राम्रो विचार हो। तर पहिले तपाईंले यो बन्द कार्यान्वयन गर्न आवश्यक छ। पहिले हामीले बन्द गर्न आवश्यक छ, र त्यसपछि हामी कसरी खोल्ने बारे सोच्नेछौं। यो सहज रूपमा खोल्नको लागि उत्कृष्ट सुविधा हो।

nginx सँग यो विकल्प छ slowly start सर्भरको लागि क्लस्टरमा। र उसले बिस्तारै लोड बनाउँछ।

हो, राम्रो विचार, हामी यसलाई प्रयास गर्नेछौं जब हामी त्यो पुग्छौं।

स्रोत: www.habr.com