PostgreSQL के लिए प्रतिकृति टोपोलॉजी परिवर्तन करना

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

एक स्टैंडबाय सर्वर का प्रचार करना

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

स्टैंडबाय सर्वर को बढ़ावा देने के लिए, आपको चलाने की जरूरत है:

[email protected]:~$ /usr/lib/postgresql/10/bin/pg_ctl promote -D /var/lib/postgresql/10/main/
waiting for server to promote.... done
server promoted

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

postgres=# select pg_last_wal_receive_lsn(), pg_last_wal_replay_lsn();
 pg_last_wal_receive_lsn | pg_last_wal_replay_lsn
-------------------------+------------------------
 1/AA2D2B08              | 1/AA2D2B08
(1 row)

सब कुछ ठीक हो जाने पर, आप पुराने प्राथमिक सर्वर को बंद कर सकते हैं और स्टैंडबाय सर्वर को बढ़ावा दे सकते हैं।

एक नए प्राथमिक सर्वर से स्टैंडबाय सर्वर को फिर से शुरू करना

आपके पास एक से अधिक स्टैंडबाय सर्वर हो सकते हैं जो आपके प्राथमिक सर्वर को बंद कर रहे हैं। आखिरकार, केवल-पढ़ने के लिए ट्रैफ़िक को ऑफ़लोड करने के लिए स्टैंडबाय सर्वर उपयोगी होते हैं। एक नए प्राथमिक सर्वर के लिए एक स्टैंडबाय सर्वर को बढ़ावा देने के बाद, आपको शेष स्टैंडबाय सर्वरों के बारे में कुछ करने की आवश्यकता है जो अभी भी पुराने प्राथमिक सर्वर से जुड़े हुए हैं (या जो कनेक्ट करने का प्रयास कर रहे हैं)। दुर्भाग्य से, आप केवल पुनर्प्राप्ति.कॉन्फ़ को नहीं बदल सकते हैं और उन्हें नए प्राथमिक सर्वर से कनेक्ट कर सकते हैं। उन्हें जोड़ने के लिए, आपको पहले उन्हें फिर से बनाना होगा। आप यहां दो तरीके आजमा सकते हैं:मानक आधार बैकअप या pg_rewind।

हम आधार बैकअप लेने के तरीके के बारे में विस्तार से नहीं जानते हैं - हमने इसे अपने पिछले ब्लॉग पोस्ट में कवर किया था, जिसमें बैकअप लेने और उन्हें PostgreSQL पर पुनर्स्थापित करने पर ध्यान केंद्रित किया गया था। यदि आप ClusterControl का उपयोग करते हैं, तो आप इसका उपयोग आधार बैकअप बनाने के लिए भी कर सकते हैं:

दूसरी ओर, pg_rewind के बारे में कुछ शब्द कहें। दोनों विधियों के बीच मुख्य अंतर यह है कि बेस बैकअप डेटा सेट की पूरी प्रतिलिपि बनाता है। अगर हम छोटे डेटासेट के बारे में बात कर रहे हैं, तो यह ठीक हो सकता है लेकिन सैकड़ों गीगाबाइट आकार (या इससे भी बड़े) वाले डेटासेट के लिए, यह जल्दी से एक समस्या बन सकता है। अंत में, आप चाहते हैं कि आपके स्टैंडबाय सर्वर जल्दी से चालू और चालू हों - अपने सक्रिय सर्वर को ऑफलोड करने के लिए और जरूरत पड़ने पर फेलओवर के लिए एक और स्टैंडबाय रखने के लिए। Pg_rewind अलग तरह से काम करता है - यह केवल उन ब्लॉक को कॉपी करता है जिन्हें संशोधित किया गया है। सब कुछ कॉपी करने के बजाय, यह केवल परिवर्तनों को कॉपी करता है, इस प्रक्रिया को काफी तेज करता है। मान लें कि आपके नए मास्टर के पास 10.0.0.103 का IP है। इस प्रकार आप pg_rewind निष्पादित कर सकते हैं। कृपया ध्यान दें कि आपको लक्ष्य सर्वर को रोकना होगा - PostgreSQL वहां नहीं चल सकता है।

[email protected]:~$ /usr/lib/postgresql/10/bin/pg_rewind --source-server="user=myuser dbname=postgres host=10.0.0.103" --target-pgdata=/var/lib/postgresql/10/main --dry-run
servers diverged at WAL location 1/AA4F1160 on timeline 3
rewinding from last common checkpoint at 1/AA4F10F0 on timeline 3
Done!

इससे ड्राई रन हो जाएगा , प्रक्रिया का परीक्षण कर रहा है लेकिन कोई बदलाव नहीं कर रहा है। अगर सब कुछ ठीक है, तो आपको बस इतना करना होगा कि इसे फिर से चलाना होगा, इस बार बिना '--ड्राई-रन' पैरामीटर के। एक बार यह हो जाने के बाद, पुनर्प्राप्ति.कॉन्फ़ फ़ाइल बनाने के लिए अंतिम शेष चरण होगा, जो नए मास्टर को इंगित करेगा। यह इस तरह दिख सकता है:

standby_mode = 'on'
primary_conninfo = 'application_name=pgsql_node_0 host=10.0.0.103 port=5432 user=replication_user password=replication_password'
recovery_target_timeline = 'latest'
trigger_file = '/tmp/failover.trigger'

अब आप अपना स्टैंडबाय सर्वर शुरू करने के लिए तैयार हैं और यह नए सक्रिय सर्वर को दोहराएगा।

जंजीर प्रतिकृति

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

दो स्टैंडबाय सर्वरों की टोपोलॉजी से एक जंजीर प्रतिकृति की ओर बढ़ना काफी सरल है।

आपको 10.0.0.103 को पुनर्प्राप्ति.कॉन्फ़ को संशोधित करना होगा, इसे 10.0.0.102 की ओर इंगित करना होगा और फिर PostgreSQL को पुनरारंभ करना होगा।

standby_mode = 'on'
primary_conninfo = 'application_name=pgsql_node_0 host=10.0.0.102 port=5432 user=replication_user password=replication_password'
recovery_target_timeline = 'latest'
trigger_file = '/tmp/failover.trigger'

पुनरारंभ करने के बाद, 10.0.0.103 को वाल अपडेट लागू करना शुरू करना चाहिए।

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