PostgreSQL क्लस्टर में विज़ार्ड की विफलता: क्या करना है?

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

1. एक ट्रिगर फ़ाइल का उपयोग करना।

प्रतिकृति को कॉन्फ़िगर करने के लिए मैनुअल कहता है कि Recovery.conf में, अन्य चीजों के अलावा, आप ट्रिगर_फाइल पैरामीटर निर्दिष्ट (और कर सकते हैं) कर सकते हैं। यहां सब कुछ सरल है - जैसे ही आप प्रतिकृति पर इस पैरामीटर में निर्दिष्ट फ़ाइल बनाते हैं, PostgreSQL पुनर्प्राप्ति प्रक्रिया को बाधित करेगा (हमारे मामले में, प्रतिकृति) और एक नई समयरेखा खोलें।
इसका मतलब है कि ट्रिगर फ़ाइल बनाने के बाद, बाइनरी लॉग काउंटर की स्थिति बदल जाएगी, और क्रमिक रूप से नहीं (कहें - 000000010000000000000043 से 000000010000000000000044 पर), लेकिन एक नए युग के साथ - (0000000 2,0000000000043 तक)।

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

बुरी खबर यह है कि यह विधि अच्छी है अगर आपके पास केवल दो सर्वर हैं - एक मास्टर और एक प्रतिकृति - क्योंकि यदि क्लस्टर में 3 या अधिक मशीनें हैं - तो आप इस नोड को अन्य प्रतिकृतियों को फिर से लोड किए बिना नया मास्टर नहीं बना सकते हैं - जब आप नए मास्टर के लिए किसी अन्य प्रतिकृति को बांधने का प्रयास करते हैं, तो PostgreSQL हमेशा के लिए निम्नलिखित कहता है:

FATAL: timeline 2 of the primary does not match recovery target timeline 1

इतिहास फ़ाइल को खिसकाने के सभी प्रकार के प्रयास (जो नए समय के लिए संक्रमण बिंदु को संग्रहीत करते हैं - यह फ़ाइल पुनर्प्राप्ति प्रक्रिया पूरी होने पर हर बार बनाई जाती है) भी विफल रही। सामान्य तौर पर, आधिकारिक मेललिस्ट में प्रतिभागी एक ही दृष्टिकोण का पालन करते हैं - इस दृष्टिकोण के साथ, अन्य प्रतिकृतियों को फिर से तैयार करना होगा (9.0 के मामले में - pg_start_backup / pg_stop_nup और rsync का उपयोग करके, और 9.1 के मामले में - pg_basebackup उपयोगिता का उपयोग करके)।

2. वसूली को दूर करना

किसी कारण से, मैनुअल में दूसरी विधि का वर्णन नहीं मिला (शायद यह वहां है और मैं पर्याप्त सावधान नहीं था - मैं बहस नहीं करूंगा)। मुझे लगता है कि आप सहमत होंगे कि यह सरल, तार्किक है और, जाहिरा तौर पर, विश्वसनीय (कम से कम - मैं दोहराया प्रयोगों की प्रक्रिया में कुछ भी पूरी तरह से तोड़ने में कामयाब नहीं हुआ):

1. पूरे क्लस्टर से, आपको नवीनतम प्रतिकृति खोजने की आवश्यकता है। आप प्रत्येक होस्ट पर कुछ करके कंसोल से ऐसा कर सकते हैं:

# ps aux|grep postg|grep rec
postgres 143 0.0 13.2 8692004 6533448 ? Ss Feb06 3:58 postgres: startup process recovering 00000001000001E500000054
postgres 2683 0.0 0.0 8699452 4044 ? Ss Feb09 0:33 postgres: wal receiver process streaming 1E5/542F9970


यदि आपके मास्टर पर उल्कापिंड अभी तक नहीं गिरा है, लेकिन आप इसे मिनट-दर-मिनट की उम्मीद करते हैं, तो मास्टर नोड को पहले से बाहर करना बेहतर होता है ताकि बाइनरी लॉग की स्थिति आपके जोड़तोड़ के दौरान बदल न जाए।

2. चयनित प्रतिकृति पर, postgresql.conf को बदल दें ताकि नोड एक मास्टर हो सके (प्रतिकृति कॉन्फ़िगरेशन मैनुअल से निम्नलिखित पैरामीटर लिया जाता है, आपके मामले में, निश्चित रूप से, मान भिन्न हो सकते हैं):
wal_level = hot_standby
max_wal_senders = 5
wal_keep_segments = 32
archive_mode = on
archive_command = 'cp %p /path_to/archive/%f'


3. संपादित करें pg_hba.conf:
host replication postgres 192.168.100.3/32 trust

4. पुनर्प्राप्ति हटाएं। नए विज़ार्ड पर वापस जाएं
5. हम नए मास्टर पर PostgreSQL का पुनः आरंभ करते हैं।
6. पुनर्प्राप्ति को संपादित करें। दूसरे प्रतिकृतियों पर (एक नया विज़ार्ड निर्दिष्ट करें) और पुनरारंभ करें।

ऐसे सरल तरीके से, आप द्विआधारी लॉग की स्थिति को खोए बिना एक प्रतिकृति को मास्टर में बदल सकते हैं। स्पष्ट कमियों में से - आपको पूरे क्लस्टर को पुनः आरंभ करना होगा (हालाँकि यदि आपके पास पुराने मास्टर से आईपी पते को नए में स्थानांतरित करने का अवसर है - तो आपको प्रतिकृतियों को फिर से शुरू करने की आवश्यकता नहीं है)।

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

सामान्य तौर पर, प्रयोगों के दौरान, एकमात्र समस्याग्रस्त स्थान जिसे हम खोजने में कामयाब रहे थे जब प्रतिकृतियों में से कुछ अब तक पिछड़ गए थे कि नए विज़ार्ड को अब XLOG फ़ाइलों की आवश्यकता नहीं है। मैंने अपनी पिछली पोस्ट में इससे कैसे निपटा जाए, यह बताया - मैं केवल यह कह सकता हूं कि यदि आप संग्रह के दौरान किसी बैकअप सर्वर पर बाइनरी लॉग भेजते हैं, तो यह समस्या शायद ही महत्वपूर्ण कही जा सकती है।