मैंने उस टूल (pglupgrad) के बारे में लिखना शुरू कर दिया है जिसे मैंने PostgreSQL क्लस्टर के लगभग-शून्य डाउनटाइम स्वचालित अपग्रेड करने के लिए विकसित किया है। इस पोस्ट में, मैं टूल के बारे में बात करूँगा और इसके डिज़ाइन विवरण पर चर्चा करूँगा।
आप श्रृंखला का पहला भाग यहां देख सकते हैं: क्लाउड में PostgreSQL क्लस्टर्स के नियर-ज़ीरो डाउनटाइम ऑटोमेटेड अपग्रेड (भाग I)।
टूल Ansible में लिखा गया है। मेरे पास Ansible के साथ काम करने का पूर्व अनुभव है, और मैं वर्तमान में इसके साथ 2ndQuadrant में भी काम करता हूं, यही वजह है कि यह मेरे लिए एक आरामदायक विकल्प था। कहा जा रहा है, आप न्यूनतम डाउनटाइम अपग्रेड लॉजिक को लागू कर सकते हैं, जिसे बाद में इस पोस्ट में अपने पसंदीदा ऑटोमेशन टूल से समझाया जाएगा।
आगे पढ़ने:ब्लॉग पोस्ट Ansible Loves PostgreSQL , PostgreSQL Planet in Ansible Galaxy और प्रस्तुति पोस्टग्रेएसक्यूएल को Ansible के साथ प्रबंधित करना।
प्लेबुक को प्लग-अपग्रेड करें
Ansible में, प्लेबुक मुख्य स्क्रिप्ट हैं जो प्रक्रियाओं को स्वचालित करने के लिए विकसित की जाती हैं जैसे कि क्लाउड इंस्टेंस को प्रोविज़न करना और डेटाबेस क्लस्टर को अपग्रेड करना। Playbooks में एक या अधिक नाटक हो सकते हैं . Playbooks में चर भी हो सकते हैं , भूमिकाएं , और हैंडलर अगर परिभाषित है।
टूल में दो मुख्य प्लेबुक शामिल हैं। पहली प्लेबुक है provision.yml जो विशिष्टताओं के अनुसार क्लाउड में Linux मशीन बनाने की प्रक्रिया को स्वचालित करता है (यह एक वैकल्पिक प्लेबुक है जो केवल क्लाउड इंस्टेंस के प्रावधान के लिए लिखी गई है और सीधे अपग्रेड से संबंधित नहीं है ) दूसरी (और मुख्य) प्लेबुक है pglupgrade.yml जो डेटाबेस क्लस्टर की अपग्रेड प्रक्रिया को स्वचालित करता है।
अपग्रेड को व्यवस्थित करने के लिए Pglupgrade प्लेबुक में आठ नाटक हैं। प्रत्येक नाटक, एक कॉन्फ़िगरेशन फ़ाइल का उपयोग करें (config.yml ), होस्ट या होस्ट समूहों पर कुछ कार्य निष्पादित करें जो होस्ट इन्वेंटरी फ़ाइल . में परिभाषित हैं (host.ini )।
इन्वेंट्री फ़ाइल
एक इन्वेंट्री फ़ाइल Ansible को यह जानने देती है कि SSH का उपयोग करके उसे किन सर्वरों से कनेक्ट करने की आवश्यकता है, इसके लिए कौन सी कनेक्शन जानकारी की आवश्यकता है, और वैकल्पिक रूप से कौन से वेरिएबल उन सर्वरों से जुड़े हैं। नीचे आप एक नमूना इन्वेंट्री फ़ाइल देख सकते हैं, जिसका उपयोग टूल के लिए डिज़ाइन किए गए केस स्टडीज में से एक के लिए स्वचालित क्लस्टर अपग्रेड को निष्पादित करने के लिए किया गया है। हम इस श्रृंखला की आगामी पोस्टों में इन केस स्टडी पर चर्चा करेंगे।
[old-primary] 54.171.211.188 [new-primary] 54.246.183.100 [old-standbys] 54.77.249.81 54.154.49.180 [new-standbys:children] old-standbys [pgbouncer] 54.154.49.180
इन्वेंट्री फ़ाइल (host.ini )
नमूना सूची फ़ाइल में पाँच होस्ट शामिल हैं पांच होस्ट समूह . के अंतर्गत जिसमें old-primary . शामिल है , new-primary , old-standbys , new-standbys और pgbouncer . एक सर्वर एक से अधिक समूहों से संबंधित हो सकता है। उदाहरण के लिए, old-standbys एक समूह है जिसमें new-standbys समूह, जिसका अर्थ है वे होस्ट जो old-standbys . के अंतर्गत परिभाषित हैं समूह (54.77.249.81 और 54.154.49.180) भी new-standbys के अंतर्गत आता है समूह। दूसरे शब्दों में, new-standbys समूह (बच्चों) से विरासत में मिला है old-standbys समूह। यह विशेष :children . का उपयोग करके प्राप्त किया जाता है प्रत्यय।
एक बार इन्वेंट्री फ़ाइल तैयार हो जाने के बाद, Ansible playbook ansible-playbook . के माध्यम से चल सकती है इन्वेंट्री फ़ाइल को इंगित करके कमांड (यदि इन्वेंट्री फ़ाइल डिफ़ॉल्ट स्थान पर स्थित नहीं है अन्यथा यह डिफ़ॉल्ट इन्वेंट्री फ़ाइल का उपयोग करेगी) जैसा कि नीचे दिखाया गया है:
$ ansible-playbook -i hosts.ini pglupgrade.yml
एक उत्तरदायी प्लेबुक चलाना
कॉन्फ़िगरेशन फ़ाइल
Pglupgrade प्लेबुक एक कॉन्फ़िगरेशन फ़ाइल का उपयोग करता है (config.yml ) जो उपयोगकर्ताओं को तार्किक उन्नयन चरों के लिए मान निर्दिष्ट करने की अनुमति देता है।
जैसा कि नीचे दिखाया गया है, config.yml मुख्य रूप से पोस्टग्रेएसक्यूएल-विशिष्ट वेरिएबल्स को स्टोर करता है जो पोस्टग्रेएसक्यूएल क्लस्टर सेट करने के लिए आवश्यक होते हैं जैसे कि postgres_old_datadir और postgres_new_datadir पुराने और नए PostgreSQL संस्करणों के लिए PostgreSQL डेटा निर्देशिका का पथ संग्रहीत करने के लिए; postgres_new_confdir नए PostgreSQL संस्करण के लिए PostgreSQL कॉन्फ़िगरेशन निर्देशिका का पथ संग्रहीत करने के लिए; postgres_old_dsn और postgres_new_dsn pglupgrade_user . के लिए कनेक्शन स्ट्रिंग को स्टोर करने के लिए pglupgrade_database . से कनेक्ट करने में सक्षम होने के लिए नए और पुराने प्राथमिक सर्वरों की। कनेक्शन स्ट्रिंग में ही विन्यास योग्य चर शामिल होते हैं ताकि उपयोगकर्ता (pglupgrade_user ) और डेटाबेस (pglupgrade_database ) विभिन्न उपयोग के मामलों के लिए जानकारी बदली जा सकती है।
ansible_user: admin
pglupgrade_user: pglupgrade
pglupgrade_pass: pglupgrade123
pglupgrade_database: postgres
replica_user: postgres
replica_pass: ""
pgbouncer_user: pgbouncer
postgres_old_version: 9.5
postgres_new_version: 9.6
subscription_name: upgrade
replication_set: upgrade
initial_standbys: 1
postgres_old_dsn: "dbname={{pglupgrade_database}} host={{groups['old-primary'][0]}} user {{pglupgrade_user}}"
postgres_new_dsn: "dbname={{pglupgrade_database}} host={{groups['new-primary'][0]}} user={{pglupgrade_user}}"
postgres_old_datadir: "/var/lib/postgresql/{{postgres_old_version}}/main"
postgres_new_datadir: "/var/lib/postgresql/{{postgres_new_version}}/main"
postgres_new_confdir: "/etc/postgresql/{{postgres_new_version}}/main" कॉन्फ़िगरेशन फ़ाइल (config.yml )
किसी भी अपग्रेड के लिए एक महत्वपूर्ण कदम के रूप में, PostgreSQL संस्करण जानकारी को वर्तमान संस्करण (postgres_old_version) के लिए निर्दिष्ट किया जा सकता है। ) और वह संस्करण जिसे अपग्रेड किया जाएगा (postgres_new_version ) भौतिक प्रतिकृति के विपरीत जहां प्रतिकृति बाइट/ब्लॉक स्तर पर सिस्टम की एक प्रति है, तार्किक प्रतिकृति चयनात्मक प्रतिकृति की अनुमति देती है जहाँ प्रतिकृति तार्किक डेटा की प्रतिलिपि बना सकती है, उसमें निर्दिष्ट डेटाबेस और उन डेटाबेस में तालिकाएँ शामिल हैं। इस कारण से, config.yml pglupgrade_database . के माध्यम से दोहराने के लिए कौन सा डेटाबेस कॉन्फ़िगर करने की अनुमति देता है चर। साथ ही, तार्किक प्रतिकृति उपयोगकर्ता को प्रतिकृति विशेषाधिकारों की आवश्यकता होती है, यही वजह है कि pglupgrade_user वेरिएबल को कॉन्फ़िगरेशन फ़ाइल में निर्दिष्ट किया जाना चाहिए। ऐसे अन्य चर हैं जो pglogic के कार्यशील आंतरिक से संबंधित हैं जैसे subscription_name और replication_set जो pglogic भूमिका में उपयोग किए जाते हैं।
प्लगग्रेड टूल की उच्च उपलब्धता डिज़ाइन
Pglupgrade टूल को विभिन्न सिस्टम आवश्यकताओं के लिए उपयोगकर्ता को उच्च उपलब्धता (HA) गुणों के संदर्भ में लचीलापन देने के लिए डिज़ाइन किया गया है। initial_standbys चर (देखें config.yml ) अपग्रेड ऑपरेशन के दौरान क्लस्टर के HA गुणों को निर्दिष्ट करने की कुंजी है।
उदाहरण के लिए, यदि initial_standbys 1 पर सेट है (किसी भी संख्या पर सेट किया जा सकता है जो क्लस्टर क्षमता की अनुमति देता है), इसका मतलब है कि प्रतिकृति शुरू होने से पहले मास्टर के साथ अपग्रेड किए गए क्लस्टर में 1 स्टैंडबाय बनाया जाएगा। दूसरे शब्दों में, यदि आपके पास 4 सर्वर हैं और आप प्रारंभिक_स्टैंडबाय को 1 पर सेट करते हैं, तो आपके पास अपग्रेड किए गए नए संस्करण में 1 प्राथमिक और 1 स्टैंडबाय सर्वर होगा, साथ ही पुराने संस्करण में 1 प्राथमिक और 1 स्टैंडबाय सर्वर होगा।
यह विकल्प मौजूदा सर्वर का पुन:उपयोग करने की अनुमति देता है जबकि नवीनीकरण अभी भी हो रहा है। 4 सर्वरों के उदाहरण में, पुराने प्राथमिक और स्टैंडबाय सर्वरों को प्रतिकृति समाप्त होने के बाद 2 नए स्टैंडबाय सर्वरों के रूप में फिर से बनाया जा सकता है।
जब initial_standbys चर 0 पर सेट है, प्रतिकृति शुरू होने से पहले नए क्लस्टर में कोई प्रारंभिक स्टैंडबाय सर्वर नहीं बनाया जाएगा।
यदि initial_standbys कॉन्फ़िगरेशन भ्रमित करने वाला लगता है, चिंता न करें। जब हम दो अलग-अलग केस स्टडी पर चर्चा करेंगे तो इसे अगले ब्लॉग पोस्ट में बेहतर तरीके से समझाया जाएगा।
अंत में, कॉन्फ़िगरेशन फ़ाइल पुराने और नए सर्वर समूहों को निर्दिष्ट करने की अनुमति देती है। यह दो तरह से प्रदान किया जा सकता है। सबसे पहले, यदि कोई मौजूदा क्लस्टर है, तो सर्वर के आईपी पते (बेयर-मेटल या वर्चुअल सर्वर हो सकते हैं ) hosts.ini . में दर्ज किया जाना चाहिए अपग्रेड ऑपरेशन के दौरान वांछित HA गुणों पर विचार करके फ़ाइल करें।
दूसरा तरीका provision.yml को चलाना है प्लेबुक (इस तरह मैंने क्लाउड इंस्टेंस का प्रावधान किया लेकिन आप अपनी खुद की प्रोविज़निंग स्क्रिप्ट या मैन्युअल रूप से प्रावधान इंस्टेंस का उपयोग कर सकते हैं ) क्लाउड में खाली Linux सर्वर (AWS EC2 इंस्टेंस) का प्रावधान करने के लिए और सर्वर के IP पते hosts.ini में प्राप्त करें फ़ाइल। किसी भी तरह, config.yml होस्ट की जानकारी hosts.ini . के माध्यम से प्राप्त होगी फ़ाइल।
अपग्रेड प्रक्रिया का कार्यप्रवाह
कॉन्फ़िगरेशन फ़ाइल की व्याख्या करने के बाद (config.yml ) जिसका उपयोग pglupgrade playbook द्वारा किया जाता है, हम अपग्रेड प्रक्रिया के वर्कफ़्लो की व्याख्या कर सकते हैं।
प्लग-ग्रेड वर्कफ्लो
जैसा कि ऊपर दिए गए आरेख से देखा जा सकता है, छह सर्वर समूह हैं जो शुरुआत में कॉन्फ़िगरेशन के आधार पर उत्पन्न होते हैं (दोनों hosts.ini और config.yml ) new-primary और old-primary समूहों में हमेशा एक सर्वर होगा, pgbouncer समूह में एक या अधिक सर्वर हो सकते हैं और सभी स्टैंडबाय समूहों में शून्य या अधिक सर्वर हो सकते हैं। कार्यान्वयन के अनुसार, पूरी प्रक्रिया को आठ चरणों में विभाजित किया गया है। प्रत्येक चरण pglupgrade प्लेबुक में एक नाटक से मेल खाता है, जो असाइन किए गए होस्ट समूहों पर आवश्यक कार्य करता है। अपग्रेड प्रक्रिया को निम्नलिखित नाटकों के माध्यम से समझाया गया है:
- कॉन्फ़िगरेशन के आधार पर होस्ट बनाएं: तैयारी का खेल जो कॉन्फ़िगरेशन के आधार पर सर्वर के आंतरिक समूह बनाता है। इस नाटक का परिणाम (
hosts.ini. के संयोजन में) सामग्री) छह सर्वर समूह हैं (कार्यप्रवाह आरेख में विभिन्न रंगों के साथ सचित्र) जिनका उपयोग निम्नलिखित सात नाटकों द्वारा किया जाएगा। - प्रारंभिक स्टैंडबाय के साथ नया क्लस्टर सेटअप करें: नए प्राथमिक और प्रारंभिक स्टैंडबाय (यदि कोई परिभाषित हैं) के साथ एक खाली PostgreSQL क्लस्टर सेट करता है। यह सुनिश्चित करता है कि पिछले उपयोग से पोस्टग्रेएसक्यूएल इंस्टॉलेशन से कोई शेष नहीं है।
- तार्किक प्रतिकृति का समर्थन करने के लिए पुराने प्राथमिक को संशोधित करें: पीजीलॉजिकल एक्सटेंशन स्थापित करता है। फिर सभी तालिकाओं और अनुक्रमों को प्रतिकृति में जोड़कर प्रकाशक को सेट करता है।
- नए प्राथमिक को दोहराएं: सब्सक्राइबर को नए मास्टर पर सेट करता है जो तार्किक प्रतिकृति शुरू करने के लिए ट्रिगर के रूप में कार्य करता है। यह नाटक मौजूदा डेटा की नकल समाप्त करता है और प्रतिकृति शुरू करने के बाद से जो बदल गया है उसे पकड़ना शुरू कर देता है।
- pgbouncer (और एप्लिकेशन) को नए प्राथमिक में बदलें: जब प्रतिकृति अंतराल शून्य में परिवर्तित हो जाता है, तो एप्लिकेशन को धीरे-धीरे स्विच करने के लिए pgbouncer को रोक देता है। फिर यह pgbouncer config को नए प्राइमरी में इंगित करता है और तब तक प्रतीक्षा करता है जब तक कि प्रतिकृति अंतर शून्य न हो जाए। अंत में, pgbouncer को फिर से शुरू किया जाता है और सभी प्रतीक्षा लेनदेन को नए प्राथमिक में प्रचारित किया जाता है और वहां प्रसंस्करण शुरू होता है। प्रारंभिक स्टैंडबाय पहले से ही उपयोग में हैं और पढ़ने के अनुरोधों का जवाब दें।
- पुराने प्राथमिक और नए प्राथमिक के बीच प्रतिकृति सेटअप को साफ करें: पुराने और नए प्राथमिक सर्वर के बीच संबंध समाप्त करता है। चूंकि सभी अनुप्रयोगों को नए प्राथमिक सर्वर पर ले जाया जाता है और उन्नयन किया जाता है, तार्किक प्रतिकृति की अब आवश्यकता नहीं है। प्राथमिक और स्टैंडबाय सर्वर के बीच प्रतिकृति भौतिक प्रतिकृति के साथ जारी है।
- पुराना क्लस्टर बंद करें: पोस्टग्रेज़ सेवा पुराने होस्ट में बंद कर दी गई है ताकि यह सुनिश्चित किया जा सके कि कोई भी एप्लिकेशन अब इससे कनेक्ट न हो सके।
- नए प्राथमिक के लिए शेष स्टैंडबाय पुन:कॉन्फ़िगर करें: यदि प्रारंभिक स्टैंडबाय के अलावा कोई शेष होस्ट है तो अन्य स्टैंडबाय का पुनर्निर्माण करता है। दूसरे मामले के अध्ययन में, पुनर्निर्माण के लिए कोई स्टैंडबाय सर्वर नहीं हैं। यह चरण पुराने प्राथमिक सर्वर को नए स्टैंडबाय के रूप में फिर से बनाने का मौका देता है यदि host.ini पर नए-स्टैंडबाय समूह में इंगित किया गया हो। pglupgrad टूल के दो-चरण स्टैंडबाय कॉन्फ़िगरेशन डिज़ाइन का उपयोग करके मौजूदा सर्वर (यहां तक कि पुराने प्राथमिक) की पुन:प्रयोज्यता प्राप्त की जाती है। उपयोगकर्ता निर्दिष्ट कर सकता है कि कौन से सर्वर अपग्रेड से पहले नए क्लस्टर के स्टैंडबाय बनने चाहिए, और कौन से अपग्रेड के बाद स्टैंडबाय बनने चाहिए।
निष्कर्ष
इस पोस्ट में, हमने कार्यान्वयन विवरण और pglupgrade टूल के उच्च उपलब्धता डिज़ाइन पर चर्चा की। ऐसा करने में, हमने उदाहरण के रूप में टूल का उपयोग करते हुए Ansible Development (यानी प्लेबुक, इन्वेंट्री और कॉन्फिग फाइल) की कुछ प्रमुख अवधारणाओं का भी उल्लेख किया है। हमने अपग्रेड प्रक्रिया के वर्कफ़्लो का वर्णन किया है और संक्षेप में बताया है कि प्रत्येक चरण संबंधित प्ले के साथ कैसे काम करता है। हम इस शृंखला की आगामी पोस्टों में केस स्टडी दिखाकर pglupgrade की व्याख्या करना जारी रखेंगे।
पढ़ने के लिए धन्यवाद!
