लोड के तहत PostgreSQL 9.0 से 9.2 तक चल रहा है

सभी को शुभ दिन!
जैसा कि आप जानते हैं, हाल ही में बहुत सारी रोचक और उपयोगी चीजों के साथ PostgreSQL 9.2 जारी किया गया । दो बार सोचने के बिना, हमने अपने स्ट्रीमिंग प्रतिकृति क्लस्टर को 9.0 से 9.2 तक अपग्रेड करने का निर्णय लिया। सब कुछ ठीक होगा अगर यह कुछ परिस्थितियों के लिए नहीं था:

• यह एक बड़ी दैनिक उपस्थिति के साथ एक उत्पादन है।
• डाउनटाइम को बाहर रखा गया है।

खैर, यह और भी दिलचस्प है ... हमने यह कैसे किया और इस पर क्या आया यह पढ़ें।

यह सब क्यों?

• PostgreSQL 9.2 में शुरू किए गए बन्स पाने की इच्छा;
• Flashcache के साथ सर्वर पर PostgreSQL विज़ार्ड का स्थानांतरण।

दिए गए:

• 3 हार्डवेयर सर्वर, जिनमें से दो मास्टर + स्लेव 9.0 का एक गुच्छा होस्ट करते हैं और फ्लैशचैच के साथ एक अन्य बिना लाइसेंस वाला सर्वर;
• बंडल को देशी स्ट्रीमिंग प्रतिकृति का उपयोग करके दोहराया जाता है।
• एप्लिकेशन के साथ चार बैकएंड और स्फिंक्स के साथ एक मशीन डेटाबेस सर्वर के साथ लगातार काम कर रहे हैं।

कठिनाई:

• क्लस्टर काम नहीं करेगा यदि आप पैकेज को 9.0 से 9.2 पर अपग्रेड करते हैं (क्लस्टर को पुनर्निवेशित या अद्यतन किया जाना चाहिए);
• क्लस्टर रोकने के बिना pg_upgrad संभव नहीं है;
• पुनर्संरचना और बाद के pg_restore या तो नहीं किया जा सकता है, क्योंकि डाउनटाइम;
• आप पहले विज़ार्ड को अपडेट नहीं कर सकते हैं, और फिर दास को अपडेट कर सकते हैं। प्रमुख संस्करणों के बीच स्ट्रीम प्रतिकृति काम नहीं करेगी।

हमने कैसे रास्ता निकाला?
Skytools-3.0 पैकेज से Londiste के उपयोग में निकास, एक बार जब हम पहले से ही इसके साथ 8.4 से 9.0 तक चले गए, तो अनुभव है। लोंडिस्ट के साथ प्रतिकृति सुविधाजनक है क्योंकि यह आपको एक क्लस्टर में व्यक्तिगत तालिकाओं और डेटाबेस को दोहराने की अनुमति देता है (उदाहरण के लिए, प्रतिकृति की स्ट्रीमिंग, पूरे क्लस्टर की प्रतिकृति)। साथ ही, अंतिम चाल के संबंध में, अब हमारे पास स्ट्रीमिंग प्रतिकृति है। और यह कोई समस्या भी नहीं है। Londiste के माध्यम से दोहराया जाने वाला डेटा तुरंत स्ट्रीमिंग प्रतिकृति का उपयोग करके हौसले से उठाए गए दास 9.2 पर दोहराया जाएगा। एक उत्कृष्ट योजना सामने आती है: 9.2 तक दोहराए जाने पर, हम पारदर्शी रूप से दास 9.2 के साथ डेटा भरेंगे। तो समस्या की योजना और एल्गोरिथ्म:



1. व्यवस्थापक भाग:

• गुरु और दास को बढ़ाओ 9.2। गुलाम 9.2 को पोर्ट 6543 पर लॉन्च किया गया है, क्योंकि मानक पोर्ट पहले से ही लिया गया है (चित्र देखें);
• उनके बीच स्ट्रीमिंग प्रतिकृति बढ़ाएँ;
• एक नए रूप से कॉन्फ़िगर किए गए विज़ार्ड 9.2 पर Skytools स्थापित करें;
• कॉन्डोम कॉन्फ़िगर करें। मास्टर 9.0 से हम प्रदाता बनाते हैं, मास्टर 9.2 से हम ग्राहक बनाते हैं;
• हम मास्टर 9.2 लोंडिस्ट और pgqd पर शुरू करते हैं, फिर हम लिंडिस्ट में निर्मित उपकरणों का उपयोग करके बंडल की संचालन क्षमता की जांच करते हैं;
• प्रदाता की ओर से, हम प्रतिकृति में सभी तालिकाओं और अनुक्रमों को जोड़ते हैं (यह ध्यान दिया जाना चाहिए कि तालिकाएं जो प्रतिकृति के लिए सक्षम हैं, केवल वे हैं जिनके पास प्राथमिक कुंजी हैं। यदि कुंजियों के बिना तालिकाएं हैं, तो आपको वहां चाबियाँ बनाने की आवश्यकता है या उन्हें हाथ से स्थानांतरित करना होगा ... हमारे पास एक हिस्सा था ऐसी योजनाएँ जो वहाँ कीज़ बनाने के लिए सौंपने के लिए सस्ती थीं);
• हम उन योजनाओं और तालिकाओं को निर्धारित करते हैं जिन्हें हाथ से स्थानांतरित करने की आवश्यकता होगी;
• सब्सक्राइबर पर, हम परीक्षण तालिका की प्रतिकृति शुरू करते हैं और लॉग से हम यह सुनिश्चित करते हैं कि प्रदाता 9.0 से डेटा सब्सक्राइबर 9.2 पर जाता है और फिर स्ट्रीमिंग प्रतिकृति के माध्यम से 9.2 गुलाम हो जाता है।

तो तकनीकी पक्ष से सब कुछ तैयार है। अब यह प्रतिकृति की प्रगति और स्विचिंग के क्षण की योजना बना रहा है। शनिवार को स्विचिंग डे के रूप में चुना गया है। अगर कुछ गलत होता है, तो हमारे पास रविवार बाकी है। हमने घटनाओं को दो चरणों में बांटा, प्रारंभिक चरण और स्विचिंग चरण। स्विचिंग कैसे की जाएगी? ऐसा करने के लिए, हमने नए 9.2 बंडल के लिए दो नए डीएनएस नाम पेश किए: डीबी-मास्टर और डीबी-दास। सही समय पर, हम इन नामों को बैकएंड कॉन्फ़िगरेशन में लिखेंगे और अनुप्रयोगों को फिर से शुरू करेंगे।
तैयारी योजना की कुछ गतिविधियाँ पहले ही ऊपर वर्णित की जा चुकी हैं, लेकिन पूर्णता के लिए, मैं अभी भी कुछ समय के लिए नहीं छोड़ूंगा:

शुक्रवार तक:

• एक नया क्लस्टर बढ़ाएँ pg-9.2;
• lgiste को pg-9.0 और pg-9.2 के बीच कॉन्फ़िगर करें;
• पड़ोसी बंदरगाह पर नया गुलाम .pg-9.2 और मास्टर के साथ स्ट्रीमिंग प्रतिकृति को कॉन्फ़िगर करें ।pg-9.2;
• किसी भी कार्यदिवस के लिए मास्टर 9.0 और गुलाम 9.0 से ताजा pgfouine रिपोर्ट तैयार करें। शीर्ष क्वेरी योजनाओं की तुलना करने के लिए रिपोर्ट की आवश्यकता होगी;
• उन सभी योजनाओं में लांड्री प्रदाता को जोड़ें जिन्हें प्राथमिक कुंजी के निर्माण की आवश्यकता नहीं है;
• सभी की जाँच के बाद नए PostgreSQL उदाहरणों से जुड़ने की क्षमता का समर्थन करता है;
• नए डेटाबेस, कनेक्शन सीमा, ऑटो-वैक्यूम सेटिंग्स के लिए डबल-चेक कॉन्फ़िगरेशन;
• नए डेटाबेस के लिए मॉनिटरिंग कॉन्फ़िगर करना (हम स्व-लिखित बैश स्क्रिप्ट के साथ युग्मित zabbix का उपयोग करते हैं जो pg_stat * टेबल को खींचते हैं);
• नए डेटाबेसों के लिए नए dns नाम db-master और db-slave बनाएं;
• शनिवार को काम के बारे में संपादकों को चेतावनी देने के लिए (यह सिर्फ शीर्ष के लिए एक चेतावनी है इसलिए वे तैयार थे, और अगर कुछ हुआ तो सवाल नहीं पूछा)।

शुक्रवार:

• रात के आयात को अक्षम करें (यह नारकीय डेटा आयात है, तंत्र ऐसा है कि 100% लॉन्डिस्ट प्रतिकृति को तोड़ता है। यह परियोजना की आंतरिक रसोई है, लेकिन मैं इसका उल्लेख करता हूं क्योंकि किसी भी परियोजना में एक समान घटक हो सकता है, इसलिए आपको सभी तत्वों पर विचार करना चाहिए जो ऑपरेशन के उद्देश्य को प्रभावित करते हैं - डेटाबेस );
• londist के माध्यम से डेटा स्थानांतरण शुरू करें। जब ग्राहक में एक तालिका जोड़ी जाती है, तो नकल तंत्र को COPY के माध्यम से शुरू किया जाता है, जिसके बाद तालिका की सुसंगत स्थिति तय हो जाती है और इसे प्रतिकृति माना जाता है);
• मैनुअल स्थानांतरण के लिए योजनाओं की एक सूची तैयार करें;

शनिवार: यह स्विचिंग का दिन है:

• मास्टर और दास से 9.2 तक शीर्ष 10 प्रश्नों की जांच करें (शायद खेल सिर्फ मोमबत्ती के लायक नहीं है?)।
• योजनाओं के मैनुअल हस्तांतरण के लिए आदेश तैयार करें (कंसोल में उन्हें हथौड़ा दें और सही समय पर एंटर दबाएं);

11.00-12.00 संपादन का निलंबन:

• मुकुट बंद करो, पृष्ठभूमि कार्यों के डेमन और सक्रिय कार्यों के पूरा होने की प्रतीक्षा करें;
• निकट संपादन (इस समय, एप्लिकेशन के लिए डेटाबेस की ओर से एप्लिकेशन को लिखना असंभव है, इस तरह हम साइट के क्लाइंट्स से डेटाबेस को एडिट करने और असंगत डेटा के जोखिम से बचेंगे, जब बैकएंड पर एप्लिकेशन फिर से शुरू होते हैं);
• शेष सर्किट को एक नए डेटाबेस में डंप करें;

12.00-12.30 स्विचिंग:

• पतन लोंदिस्ट प्रतिकृति (प्रदर्शन तालिकाओं, अनुक्रम, नोड्स, स्टॉप लोंडिस्ट और पीजीक्यूडी);
• बैकएंड पर फिक्स कॉन्फिग;
• बैकएंड पर आवेदन पुनः आरंभ करें (nginx + यात्री);
• स्फिंक्स के लिए कॉन्फ़िगरेशन को अपडेट करें और इसे पुनरारंभ करें;

वह सब है। उसके बाद, londiste के माध्यम से प्रतिकृति असंगत हो जाती है, क्योंकि संपूर्ण बाहरी रिकॉर्ड (साइट पर रिकॉर्ड स्रोत क्लाइंट है) क्लस्टर 9.2 पर चला गया;

• पृष्ठभूमि टास्क डेमॉन के कॉन्फ़िगरेशन को ठीक करें और इसे चलाएं। मुकुट चलाएं;
• खुला संपादन;
• सभी नियंत्रण खोलें और संभावित जाम की तलाश करें।

स्विच करने के बाद:

• रात का आयात सक्षम करें;
• Cron लॉग, पृष्ठभूमि कार्यों के डेमन लॉग, प्रतिकृति लॉग की जाँच करें।

हिलाने के बाद

• इसके लिए db-slave को मानक पोर्ट में ट्रांसफर करें:
• स्वामी के साथ काम करने के लिए एक दास के साथ काम करने वाले बैकएंड स्विच;
• pg-9.0 बंद करें;
• पूर्ण मेमोरी के साथ काम करने के लिए नए pg-9.2 को कॉन्फ़िगर करें (यह अविस्मरणीय है कि मेजबान पर 2 पोस्टग्रेसीएस इंस्टेंसेस थे, इसलिए मुझे उनके बीच मेमोरी को विभाजित करना पड़ा);
• पोर्ट 5432 पर db-slave चलाएं, बैकएंड से और स्फिंक्स से कनेक्शन की जांच करें;
• अखंडता की जाँच करें और प्रतिकृति की अंतराल;
• बैकेंड की तरफ एक दास रखें।

रोलबैक। कुछ गलत हो जाने की स्थिति में एक योजना:

• करीबी संपादन;
• पृष्ठभूमि कार्यों और मुकुट के डेमन को रोकें, सक्रिय कार्यों के पूरा होने की प्रतीक्षा करें;
• डेटाबेस सर्वर नामों को मूल लोगों के लिए कॉन्फ़िगर करें, बैकएंड्स को पुनरारंभ करें, पृष्ठभूमि कार्यों का डेमॉन शुरू करें;
• स्फिंक्स के लिए कॉन्फ़िगरेशन को वापस रोल करें;
• खुला संपादन।

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

# for i in schema_1 schema_2 schema_3; do psql -ltAF. -U postgres -c "\dt $i." db_name |cut -d. -f1,2 ; done |while read line ; do echo "$line" - $(psql -qAtX -U postgres -c "select count() from $line" db_name); done 

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

अच्छा, थोड़ा सा रेखांकन।
1. नयालरी। बैकएंड स्विचिंग प्रक्रिया


2. ज़बबिक्स। PG 9.0 के साथ दैनिक सर्वर संचालन (सोमवार, 10 सितंबर)


3. ज़ाबिक्स। सर्वर दिन चलने पीजी 9.0 (सोमवार 10 सितंबर)


4. ज़बबिक्स। PG 9.2 / FlashCache के साथ दैनिक सर्वर ऑपरेशन (सोमवार, 17 सितंबर)


5. ज़बबिक्स। पीजी 9.2 + फ्लैशकेच के साथ सर्वर डे टाइम (सोमवार 17 सितंबर)


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

तकनीकी विवरण के बारे में कौन परवाह करता है:
देखें कि PostgreSQL में थ्रेड प्रतिकृति कैसे कॉन्फ़िगर की गई है, यहां देखें।
Skytools-3 का उपयोग करके PostgreSQL समूहों के बीच तालिका प्रतिकृति को कैसे कॉन्फ़िगर किया गया है, यहां देखें।

यह एक सबबॉटनिक की कहानी है। आपका ध्यान के लिए धन्यवाद!