बैकएंड इंटरव्यू: आप PostgreSQL लॉजिकल-रेप्लिकेशन फेलओवर को कैसे डिज़ाइन करेंगे?

प्रॉम्प्ट और दायरा

आप एक CDC कंज्यूमर संचालित करते हैं जो प्रोडक्शन PostgreSQL डेटाबेस से परिवर्तनों को पढ़ता है। एक नियोजित स्विचओवर या अप्रत्याशित विफलता के दौरान, आप नए प्राइमरी को डुप्लिकेट्स, अंतराल (gaps), WAL संचय (buildup), या अनुचित ज़ीरो-लॉस के दावे को छिपाए बिना उसी लॉजिकल रेप्लिकेशन स्लॉट को जारी रखने की अनुमति कैसे देंगे? PostgreSQL 18 फेलओवर स्लॉट्स, सिंक्रोनाइज़ेशन चेक, कंज्यूमर रीकनेक्ट्स, मॉनिटरिंग और रोलबैक की व्याख्या करें।

PostgreSQL दस्तावेज़ यह स्पष्ट करते हैं कि लॉजिकल रेप्लिकेशन स्लॉट्स को एक फिजिकल स्टैंडबाय के साथ सिंक्रोनाइज़ किया जा सकता है, लेकिन स्लॉट सिंक्रोनाइज़ेशन एसिंक्रोनस (asynchronous) होता है। स्टैंडबाय को प्रमोट करने से पहले, आवश्यक स्लॉट्स मौजूद होने चाहिए और failover_ready के रूप में रिपोर्ट किए जाने चाहिए। यह बैकएंड विश्वसनीयता प्रश्न यह परीक्षण करता है कि क्या आप डेटाबेस क्षमताओं, कंज्यूमर सिमेंटिक्स और फेलओवर ऑर्केस्ट्रेशन को एक सत्यापन योग्य प्रक्रिया में जोड़ सकते हैं।

साक्षात्कारकर्ता क्या मूल्यांकन करता है

• फिजिकल WAL रेप्लिकेशन, लॉजिकल रेप्लिकेशन स्लॉट्स और कंज्यूमर एक्नॉलेजमेंट्स में अंतर करना।
• failover स्लॉट विकल्प और synchronized_standby_slots की सीमाओं की व्याख्या करना।
• अलग-अलग लॉस और डुप्लिकेशन विंडो के साथ नियोजित स्विचओवर और अचानक विफलताओं को संभालना।
• यह जानना कि एक लाइव स्टैंडबाय इस बात का प्रमाण नहीं है कि प्रत्येक लॉजिकल स्लॉट तैयार है।
• WAL रिटेंशन, स्लॉट लैग, रीकनेक्ट्स और कंज्यूमर डिले के लिए अलर्ट डिज़ाइन करना।
• कनेक्शन डिस्कवरी, फेंसिंग और डाउनस्ट्रीम इडेम्पोटेंसी को स्पष्ट घटकों को सौंपना।

पूछने के लिए स्पष्टीकरण प्रश्न

1. क्या कंज्यूमर कोई अन्य PostgreSQL सब्सक्राइबर है या गैर-PostgreSQL CDC क्लाइंट जैसे Debezium? रेडीनेस चेक भिन्न होते हैं।
2. क्या लक्ष्य एक नियोजित नियर-ज़ीरो-लॉस स्विच है या क्रैश के बाद एक सीमित रिकवरी पॉइंट?
3. क्या डाउनस्ट्रीम LSN, ट्रांजेक्शन ID, इवेंट ID, या बिजनेस की (business key) द्वारा डुप्लिकेट्स हटा सकता है?
4. क्या प्राइमरी और स्टैंडबाय समान PostgreSQL मेजर वर्ज़न और आउटपुट प्लगइन का उपयोग करते हैं?
5. कौन सा कोऑर्डिनेटर स्टैंडबाय को प्रमोट करता है, डिस्कवरी बदलता है, पुराने प्राइमरी को फेंस करता है, और स्प्लिट-ब्रेन को रोकता है?

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

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

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

1. डेटा सिमेंटिक्स को परिभाषित करें

RPO, RTO और डुप्लिकेट हैंडलिंग को डिज़ाइन में शामिल करें। एक नियोजित स्विचओवर आवश्यक स्लॉट्स के सिंक्रोनाइज़ होने की प्रतीक्षा कर सकता है; अचानक विफलता केवल उस WAL से ही रिकवर हो सकती है जो प्रमोट किए गए स्टैंडबाय तक पहुँचा हो। कंज्यूमर को अपना अंतिम कन्फर्म LSN या समकक्ष स्थिति बनाए रखनी चाहिए, और साइड इफेक्ट्स के लिए इडेम्पोटेंसी कीज़ का उपयोग करना चाहिए।

2. फेलओवर-सक्षम लॉजिकल स्लॉट्स कॉन्फ़िगर करें

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

-- Illustrative only: allow a logical slot to synchronize to a standby
SELECT *
FROM pg_create_logical_replication_slot('cdc_orders', 'pgoutput', false, true);

सटीक सिग्नेचर और अनुमतियाँ डिप्लॉय किए गए PostgreSQL वर्ज़न और प्लगइन से मेल खानी चाहिए। यह उदाहरण कॉन्फ़िगरेशन और कम्पैटिबिलिटी चेक्स की जगह नहीं ले सकता।

3. फिजिकल रेप्लिकेशन के माध्यम से स्लॉट स्थिति को आगे बढ़ाएँ

WAL प्राप्त करने के लिए फिजिकल स्टैंडबाय को कॉन्फ़िगर करें और जहाँ प्रलेखित फेलओवर वर्कफ़्लो की आवश्यकता हो वहाँ synchronized_standby_slots का उपयोग करें। प्रमोशन से पहले, स्टैंडबाय पर pg_replication_slots का निरीक्षण करें और पुष्टि करें कि प्रत्येक आवश्यक स्लॉट मौजूद है, सिंक्रोनाइज़ है, और failover_ready है। स्लॉट कॉपी करना एसिंक्रोनस है, इसलिए केवल एक स्वस्थ स्ट्रीमिंग कनेक्शन पर्याप्त नहीं है।

4. नियोजित स्विचओवर

CDC कंज्यूमर्स को रोकें (pause) या खाली (drain) करें और उनकी अंतिम कन्फर्म स्थितियों को रिकॉर्ड करें। पुराने प्राइमरी पर राइट्स (writes) रोकें और फिजिकल रेप्लिकेशन तथा स्लॉट सिंक्रोनाइज़ेशन की प्रतीक्षा करें। दोनों नोड्स पर स्लॉट इन्वेंट्री का मिलान करें, सभी आवश्यक स्लॉट तैयार होने के बाद ही प्रमोट करें, फिर कनेक्शन डिस्कवरी बदलें और उसी लॉजिकल स्लॉट से कंज्यूमर्स को फिर से शुरू करें। यदि सीमा को रीप्ले किया जाता है, तो डाउनस्ट्रीम LSN चेक या इडेम्पोटेंसी डुप्लिकेट प्रभावों को हटा देते हैं।

5. अचानक विफलता और स्प्लिट-ब्रेन सुरक्षा

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

6. WAL रिटेंशन और कंज्यूमर प्रगति की निगरानी करें

प्रत्येक स्लॉट के restart_lsn, confirmed_flush_lsn, स्लॉट लैग, रिटेन्ड WAL, रीकनेक्ट काउंट और एंड-टू-एंड डिले को ट्रैक करें। एक परित्यक्त (abandoned) स्लॉट WAL रीसाइक्लिंग को रोक सकता है और डिस्क को भर सकता है। "स्लॉट मौजूद है" के अलर्ट को "कंज्यूमर ने टारगेट LSN तक प्रोसेस कर लिया है" से अलग करें, और रिकवरी के लिए टाइमआउट, थ्रॉटल और मानवीय हस्तक्षेप थ्रेसहोल्ड सेट करें।

7. रोलबैक, रीबिल्ड और स्वीकृति

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

उच्च गुणवत्ता वाला नमूना उत्तर

मैं वर्कफ़्लो को छह स्थितियों के रूप में मॉडल करूँगा: स्लॉट तैयार हैं, पुराना प्राइमरी फेंस है, स्टैंडबाय प्रमोट है, डिस्कवरी स्विच हो गई है, कंज्यूमर फिर से शुरू हो गए हैं, और डाउनस्ट्रीम स्थितियों की पुष्टि हो गई है। मैं आवश्यक लॉजिकल स्लॉट्स के लिए फेलओवर सक्षम करूँगा और स्टैंडबाय पर synchronized_standby_slots और pg_replication_slots का तब तक निरीक्षण करूँगा जब तक कि प्रत्येक स्लॉट मौजूद न हो और failover_ready न हो जाए। चूँकि सिंक्रोनाइज़ेशन एसिंक्रोनस है, इसलिए सुरक्षित प्रमोशन के लिए केवल लाइव स्टैंडबाय ही पर्याप्त प्रमाण नहीं है।

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

सामान्य गलतियाँ

• स्टैंडबाय ऑनलाइन होने के कारण प्रमोट करना → स्लॉट सिंक्रोनाइज़ेशन अभी भी अधूरा हो सकता है → प्रत्येक स्लॉट की उपस्थिति, सिंक स्थिति और failover_ready की जाँच करें।
• लॉजिकल स्लॉट को इस बात का प्रमाण मानना कि कंज्यूमर ने डेटा प्रोसेस कर लिया है → स्लॉट स्थिति डाउनस्ट्रीम एक्नॉलेजमेंट से भिन्न होती है → LSNs और कंज्यूमर स्थितियों को अलग से ट्रैक करें।
• क्रैश के लिए ज़ीरो लॉस का वादा करना → अनसिंक्रोनाइज़्ड WAL अनुपलब्ध हो सकता है → नियोजित और अनियोजित RPO को अलग-अलग बताएं।
• पुराने प्राइमरी को फेंस किए बिना DNS बदलना → स्प्लिट-ब्रेन राइट्स संभव बने रहते हैं → पहले फेंस करें, फिर प्रमोट करें और डिस्कवरी बदलें।
• रुके हुए स्लॉट की अनदेखी करना → रिटेन्ड WAL डिस्क को समाप्त कर सकता है → लैग, डिस्क और अधिकतम रिटेंशन अवधि पर अलर्ट सेट करें।
• केवल डेटाबेस प्रमोशन का परीक्षण करना → कंज्यूमर्स, प्लगइन्स और डाउनस्ट्रीम प्रभाव विफल हो सकते हैं → एंड-टू-एंड रीप्ले ड्रिल चलाएं।

फॉलो-अप प्रश्न और उत्तर

क्या failover_ready यह साबित करता है कि कोई इवेंट नहीं छूटेगा?

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

नियोजित स्विच के दौरान कंज्यूमर्स को क्यों रोकें?

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

एक गैर-PostgreSQL CDC क्लाइंट को रेडीनेस को कैसे सत्यापित करना चाहिए?

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

क्या होगा यदि कोई स्लॉट सिंक्रोनाइज़ नहीं है लेकिन व्यवसाय को रिकवर होना ही है?

वास्तविक RPO बताएं और एक रूढ़िवादी रिकवरी पॉइंट चुनें। स्लॉट को फिर से बनाएँ, एक नया स्नैपशॉट लें, या यदि आवश्यक हो तो बैकअप से क्षतिपूर्ति करें। अप्रमाणित रेप्लिकेशन स्थिति को दोषरहित (lossless) रिकवरी के रूप में प्रस्तुत न करें।

आप पुराने प्राइमरी को वापस आने से कैसे रोकते हैं?

कोऑर्डिनेटर या क्लाउड फेंसिंग, नेटवर्क आइसोलेशन और राइट-क्रेडेंशियल रोटेशन का उपयोग करें। केवल DNS परिवर्तन पुराने प्राइमरी को राइट्स स्वीकार करने से नहीं रोक सकता।

आप कैसे साबित करते हैं कि रीप्ले से कोई डुप्लिकेट साइड इफेक्ट नहीं हुआ?

ट्रांजेक्शन LSN, इवेंट ID, या एक इडेम्पोटेंसी की द्वारा डुप्लिकेट्स को हटाएँ, फिर ड्रिल के दौरान रीप्ले काउंट्स, अंतिम व्यावसायिक योग (business totals) और ऑर्डरिंग बाधाओं को रिकॉर्ड करें। स्विच से पहले और बाद में ऑडिट योग्य स्थितियों की तुलना करें।