डेटा इंटरव्यू: PostgreSQL 18 फेलओवर के बाद लॉजिकल रेप्लिकेशन कैसे जारी रखता है?

प्रॉम्प्ट और उपयोग का मामला (यूज़ केस)

एक PostgreSQL 18 प्राइमरी लॉजिकल रेप्लिकेशन के माध्यम से एक एनालिटिक्स क्लस्टर और बाहरी सब्सक्राइबर्स को परिवर्तन भेजता है। प्राइमरी एक फिजिकल स्टैंडबाय पर फेलओवर हो सकता है। स्लॉट्स, सेटिंग्स, सब्सक्राइबर चेक्स और कटओवर क्रम को इस तरह डिज़ाइन करें कि लॉजिकल रेप्लिकेशन "स्टैंडबाय सिंक्रोनाइज़्ड है" को "सब्सक्राइबर पूरी तरह अपडेट (caught up) है" के साथ भ्रमित किए बिना सही स्थिति से फिर से शुरू हो सके।

इंटरव्यूअर क्या जांच रहा है

• क्या आप लॉजिकल स्लॉट्स, फिजिकल स्लॉट्स, WAL रिटेंशन और सब्सक्राइबर द्वारा कन्फर्म की गई स्थितियों के बीच अंतर समझते हैं।
• क्या आप समझते हैं कि फेलओवर-स्लॉट सिंक्रोनाइज़ेशन एसिंक्रोनस होता है और कटओवर से पहले इसका तैयार होना साबित किया जाना चाहिए।
• क्या आप एक सुरक्षित स्विच साबित करने के लिए pg_replication_slots, LSNs और सब्सक्रिप्शन स्थिति का उपयोग कर सकते हैं।
• क्या आप अमान्य स्लॉट्स, पिछड़ रहे सब्सक्राइबर्स, योजनाबद्ध कटओवर और अप्रत्याशित विफलताओं को संभाल सकते हैं।

उत्तर देने से पहले स्पष्ट करने योग्य प्रश्न

• क्या सब्सक्राइबर्स PostgreSQL हैं या बाहरी सिस्टम, और क्या वे नए प्राइमरी से फिर से जुड़ सकते हैं?
• क्या अनुमत RPO शून्य है, एक सीमित LSN गैप है, या एक पुनर्निर्माण योग्य सब्सक्रिप्शन स्नैपशॉट है?
• क्या प्राइमरी और स्टैंडबाय के बीच फिजिकल रेप्लिकेशन स्लॉट्स और सिंक्रोनस स्टैंडबाय बाधाएं (constraints) कॉन्फ़िगर की गई हैं?
• क्या कटओवर स्वचालित है या मैन्युअल, और राइट्स को कौन फ्रीज़ करता है और कनेक्शन रूटिंग को कौन अपडेट करता है?

30-सेकंड उत्तर ढांचा

मैं ऐसे प्रत्येक लॉजिकल स्लॉट के लिए failover सक्षम करूंगा जिसे स्विच के बाद भी बने रहना है, ताकि इसकी स्थिति हॉट स्टैंडबाय पर सिंक्रोनाइज़ हो सके। मैं फिजिकल सिंक्रोनाइज़ेशन बाधाएं भी कॉन्फ़िगर करूंगा ताकि कोई सब्सक्राइबर ऐसी प्रगति न देख सके जिसे टेकओवर करने वाले स्टैंडबाय ने सुरक्षित (persist) न किया हो। कटओवर से पहले, सत्यापित करें कि स्टैंडबाय पर प्रत्येक आवश्यक स्लॉट synced है, गैर-अस्थायी (non-temporary) है, और अमान्य नहीं हुआ है। स्टैंडबाय को प्रमोट करें, कनेक्शन अपडेट करें, सत्यापित करें कि सब्सक्राइबर्स नए प्राइमरी से डेटा प्राप्त कर रहे हैं, और फिर राइट्स को अनफ्रीज़ करें। यदि एसिंक्रोनस सिंक्रोनाइज़ेशन पीछे है, तो स्विच में देरी करें या प्रलेखित RPO और पुनर्निर्माण लागत को स्वीकार करें।

चरण-दर-चरण गहन विश्लेषण

1. लॉजिकल रेप्लिकेशन स्लॉट क्या स्टोर करता है

एक लॉजिकल स्लॉट डिकोडिंग प्रगति और WAL रिटेंशन सीमा को स्टोर करता है जिसकी सब्सक्राइबर्स द्वारा अभी तक पुष्टि नहीं की गई है। एक स्लॉट किसी सब्सक्राइबर के स्वास्थ्य का संकेत नहीं है; रुका हुआ सब्सक्राइबर प्राइमरी को WAL बनाए रखने और डिस्क स्थान का उपभोग करने के लिए मजबूर कर सकता है।

2. फेलओवर स्लॉट बनाना

PostgreSQL 18 एक लॉजिकल स्लॉट बनाते समय failover सेट करने और सब्सक्रिप्शन बनाते समय संबंधित विकल्प का समर्थन करता है। नीचे दिया गया SQL केवल उदाहरण के लिए है; लक्षित संस्करण और परिनियोजन विधि के आधार पर सटीक तर्कों और विशेषाधिकारों की पुष्टि करें।

SELECT *
FROM pg_create_logical_replication_slot('analytics_slot', 'pgoutput', false, true);

फेलओवर फ़्लैग स्लॉट स्थिति को स्टैंडबाय पर सिंक्रोनाइज़ करने की अनुमति देता है, लेकिन यह साबित नहीं करता है कि सिंक्रोनाइज़ेशन पूरा हो गया है।

3. स्टैंडबाय सिंक्रोनाइज़ेशन सेटिंग्स

स्टैंडबाय को लॉजिकल-स्लॉट सिंक्रोनाइज़ेशन प्राप्त करने और लागू करने की सुविधा सक्षम करनी होगी, जैसे कि sync_replication_slots। प्राइमरी विशेष फिजिकल स्लॉट्स को पहले अपडेट होने की आवश्यकता के लिए synchronized_standby_slots का उपयोग कर सकता है, जिससे लॉजिकल सब्सक्राइबर की प्रगति टेकओवर करने वाले स्टैंडबाय से आगे निकलने से रुक जाती है।

4. एसिंक्रोनस तत्परता को एक अलग जांच की आवश्यकता क्यों है

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

5. कटओवर से पहले स्लॉट स्थिति की जांच करना

उम्मीदवार स्टैंडबाय पर pg_replication_slots को क्वेरी करें। पुष्टि करें कि प्रत्येक आवश्यक स्लॉट सिंक्रोनाइज़्ड है, गैर-अस्थायी है, और उसमें अमान्य होने का कोई कारण नहीं है, फिर परिणाम का मिलान सब्सक्राइबर इन्वेंट्री से करें।

SELECT slot_name,
       synced,
       temporary,
       invalidation_reason,
       confirmed_flush_lsn
FROM pg_replication_slots
WHERE slot_type = 'logical';

केवल तभी जब प्रत्येक आवश्यक स्लॉट पास हो जाए, स्टैंडबाय को टेकओवर के लिए तैयार चिह्नित किया जाना चाहिए।

6. PostgreSQL सब्सक्राइबर्स के लिए अतिरिक्त जांच

PostgreSQL सब्सक्राइबर्स के लिए, यह भी पुष्टि करें कि सब्सक्राइबर ने सिंक्रोनाइज़्ड स्लॉट के साथ संगत स्थिति का उपभोग किया है। केवल फिजिकल प्राइमरी-टू-स्टैंडबाय लैग पर्याप्त नहीं है; सब्सक्रिप्शन स्थिति, अंतिम प्राप्त LSN और व्यावसायिक लैग को संयोजित करें।

7. बाहरी सब्सक्राइबर्स को स्विच करना

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

8. विफलता और रिकवरी मार्ग

एक योजनाबद्ध स्विच तब तक प्रतीक्षा कर सकता है जब तक कि सभी स्लॉट सिंक्रोनाइज़ न हो जाएं। एक अप्रत्याशित विफलता के लिए एक RPO निर्णय की आवश्यकता होती है: एक गैप स्वीकार करें, ट्रैफ़िक में देरी करें, या सब्सक्रिप्शन का पुनर्निर्माण करें। पुनर्प्राप्त पुराने प्राइमरी को तुरंत राइट पाथ में फिर से शामिल नहीं होना चाहिए; इसे अलग करें, फिजिकल रेप्लिकेशन का पुनर्निर्माण करें, और स्लॉट तथा सब्सक्रिप्शन स्थिति की पुनः जांच करें।

ट्रेड-ऑफ़ और सीमाएं

• फेलओवर स्लॉट लॉजिकल-रेप्लिकेशन रिकवरेबिलिटी में सुधार करते हैं लेकिन स्लॉट-सिंक और WAL-मॉनिटरिंग की जटिलता को बढ़ाते हैं।
• पूर्ण स्लॉट सिंक्रोनाइज़ेशन की प्रतीक्षा करने से गैप कम होते हैं लेकिन फेलओवर का समय बढ़ सकता है।
• synchronized_standby_slots फिजिकल स्टैंडबाय के सापेक्ष लॉजिकल प्रगति को रोकता है; यह प्रत्येक बाहरी सब्सक्राइबर के लिए एंड-टू-एंड शून्य डेटा हानि प्रदान नहीं करता है।
• अमान्य स्लॉट, लगभग-पूर्ण स्टोरेज और लंबे समय से रुके हुए सब्सक्राइबर्स के लिए अलर्ट और क्लीनअप की आवश्यकता होती है, न कि केवल एक कटओवर स्क्रिप्ट की।

कार्यान्वयन योजना और साक्ष्य

1. PostgreSQL 18 टेस्ट क्लस्टर में एक फेलओवर लॉजिकल स्लॉट बनाएं और प्राइमरी/स्टैंडबाय सेटिंग्स और विशेषाधिकारों को सत्यापित करें।
2. सब्सक्राइबर रुकावट, WAL बिल्डअप, असिंक्रोनाइज़्ड स्लॉट्स और अचानक प्राइमरी हानि की स्थितियां बनाएं; LSNs और रिकवरी परिणामों को रिकॉर्ड करें।
3. प्री-कटओवर pg_replication_slots क्वेरी को स्वचालित करें और इसकी स्लॉट इन्वेंट्री की सब्सक्राइबर्स के साथ तुलना करें।
4. योजनाबद्ध और अप्रत्याशित-विफलता मार्गों पर पॉज़, प्रमोशन, पुनः कनेक्ट, कैच-अप और रोलबैक का अभ्यास (ड्रिल) करें।
5. PostgreSQL 18 Logical Replication Failover, Logical Decoding और Streaming Replication दस्तावेज़ों के विरुद्ध मापदंडों और सीमाओं की समीक्षा करें।

सामान्य गलतियाँ और अनुवर्ती (फॉलो-अप) प्रश्न

गलती 1: यह मान लेना कि स्टैंडबाय डेटा का अर्थ है कि लॉजिकल टेकओवर तैयार है

स्लॉट स्थिति एसिंक्रोनस रूप से सिंक्रोनाइज़ होती है। डेटा पेजों का अपडेट होना यह साबित नहीं करता है कि स्लॉट स्थिति प्रयोग करने योग्य है; सिंक्रोनाइज़ेशन और अमान्यता फ़ील्ड्स का निरीक्षण करें।

गलती 2: केवल फिजिकल रेप्लिकेशन लैग की निगरानी करना

सब्सक्राइबर उपभोग, कन्फर्म स्लॉट LSN, बनाए रखी गई WAL और व्यावसायिक लैग की भी निगरानी करें। फिजिकल रेप्लिकेशन स्वस्थ दिखने पर भी लॉजिकल बैकलॉग बढ़ सकता है।

गलती 3: फेलओवर विकल्प को स्वचालित स्विचिंग के रूप में मानना

यह स्लॉट-स्थिति सिंक्रोनाइज़ेशन को सक्षम करता है; यह स्टैंडबाय को प्रमोट नहीं करता, कनेक्शन अपडेट नहीं करता, या बाहरी सब्सक्राइबर्स को मान्य नहीं करता है। कटओवर के लिए अभी भी ऑर्केस्ट्रेशन और अभ्यास की आवश्यकता है।

फॉलो-अप: क्या आप किसी स्लॉट के सिंक्रोनाइज़ होने से पहले प्रमोट कर सकते हैं?

केवल एक स्पष्ट RPO, गैप, या पुनर्निर्माण निर्णय के साथ। डिफ़ॉल्ट गेट को सिंक्रोनाइज़ेशन की प्रतीक्षा करनी चाहिए और परिणाम रिकॉर्ड करना चाहिए।

फॉलो-अप: आप डुप्लिकेट डेटा उपभोग से कैसे बचते हैं?

एक इवेंट आईडी या स्रोत LSN को सुरक्षित रखें, कटओवर के बाद एक सत्यापन योग्य स्थिति से फिर से शुरू करें, और पुनः चलाने (replay) के लिए इडेम्पोटेंट हैंडलिंग और समाधान (reconciliation) का उपयोग करें।