प्रश्न और संदर्भ
एक PostgreSQL 18 पब्लिशर एक एनालिटिक्स सब्सक्रिप्शन, एक ऑडिट कंज्यूमर और अस्थायी बैकफ़िल जॉब्स को सर्व करता है। कुछ कंज्यूमर ऑफ़लाइन रहते हैं, जिससे WAL रीसाइक्लिंग रुक जाती है और डिस्क तेज़ी से भरने लगती है। idle_replication_slot_timeout के लिए रोलआउट, ऑब्जर्वेबिलिटी, इनवैलिडेशन और रिकवरी डिज़ाइन करें।
साक्षात्कारकर्ता क्या मूल्यांकन करता है
- क्या आप समझाते हैं कि स्लॉट WAL को क्यों बनाए रखते हैं और एक आइडल टाइमआउट वास्तव में कब प्रभावी होता है।
- क्या आप लॉजिकल और फिजिकल स्लॉट, सब्सक्रिप्शन रिकवरी और रीबिल्ड सीमाओं के बीच अंतर करते हैं।
- क्या आप डिलीशन सेफ़गार्ड्स, अलर्टिंग, ऑडिटेबिलिटी और डिस्क-प्रेशर नियंत्रण डिज़ाइन करते हैं।
- क्या आप कंज्यूमर रिकवरी के बाद री-स्नैपशॉट (resnapshot), रीबिल्ड या मानव पुष्टि (human-confirmation) का मार्ग प्रदान करते हैं।
पहले स्पष्टीकरण वाले प्रश्न
कंज्यूमर सिमेंटिक्स
प्रत्येक स्लॉट क्या सर्व करता है? क्या डाउनटाइम का डेटा खो सकता है, या कंज्यूमर को किसी सीमा (boundary) से फिर से शुरू करना चाहिए? क्या किसी अस्थायी बैकफ़िल स्लॉट का एक स्पष्ट अधिकतम जीवनकाल है?
संसाधन और विंडो
कितना WAL और डिस्क शेष है, और प्रत्येक स्लॉट का restart_lsn और कंज्यूमर लैग क्या है? चेकपॉइंट कितनी बार चलते हैं? क्या मेंटेनेंस विंडो के दौरान सब्सक्रिप्शन या कंज्यूमर को फिर से बनाया जा सकता है?
परिवर्तन प्राधिकरण (Change Authority)
स्वचालित इनवैलिडेशन को कौन स्वीकृत करता है? क्या पहले कंज्यूमर पुष्टि, एक टिकट, या दोहरी स्वीकृति की आवश्यकता है? डिजास्टर रिकवरी या अनुपालन ऑडिट के लिए किन स्लॉट्स को स्थायी रूप से सुरक्षित किया जाना चाहिए?
30-सेकंड का उत्तर
मैं प्रत्येक स्लॉट के स्वामी, उद्देश्य, गतिविधि और बनाए रखे गए WAL की सूची बनाऊंगा, फिर महत्वपूर्ण, पुनर्प्राप्ति योग्य (recoverable) और अस्थायी स्लॉट को वर्गीकृत करूंगा। पुनर्प्राप्ति योग्य स्लॉट्स को अग्रिम अलर्ट के साथ एक आइडल टाइमआउट मिलता है; महत्वपूर्ण स्लॉट्स बिना स्वचालित इनवैलिडेशन के केवल अलर्ट भेजते हैं। चूंकि इनवैलिडेशन चेकपॉइंट के दौरान होता है, इसलिए स्लॉट की स्थिति, कारण और डिस्क मेट्रिक्स को ऑडिट ट्रेल में रिकॉर्ड करें। रिकवरी पर, डेटा-लॉस अनुबंध के अनुसार फिर से शुरू करना, री-स्नैपशॉट, या बैकअप रीस्टोर चुनें।
गहन समाधान
1. स्लॉट रिटेंशन की व्याख्या करें
एक रेप्लिकेशन स्लॉट पब्लिशर को उस WAL को बनाए रखने के लिए बाध्य करता है जिसकी आवश्यकता ऐसे कंज्यूमर को होती है जिसने इसे स्वीकार (acknowledge) नहीं किया है। एक लॉजिकल स्लॉट जिसका restart_lsn पीछे रह जाता है, WAL के जीवनकाल को बढ़ाता है; एक ऑफ़लाइन कंज्यूमर सामान्य वृद्धि को एक असीमित जोखिम में बदल सकता है। नीति निर्धारित करने से पहले स्लॉट का नाम, डेटाबेस, प्लगइन, कंज्यूमर और स्वामी रिकॉर्ड करें।
2. स्लॉट्स को वर्गीकृत करें
महत्वपूर्ण (critical), पुनर्प्राप्ति योग्य (recoverable) और अस्थायी (temporary) श्रेणियों का उपयोग करें। महत्वपूर्ण स्लॉट्स के लिए मानवीय कार्रवाई और बड़े क्षमता बजट की आवश्यकता होती है। पुनर्प्राप्ति योग्य स्लॉट चेतावनियों के बाद समाप्त हो सकते हैं। अस्थायी स्लॉट निर्माण के समय एक समाप्ति समय प्राप्त करते हैं। संरक्षित सूची को कंज्यूमर द्वारा सबमिट किए गए कॉन्फ़िगरेशन से बाहर रखें ताकि कोई एप्लिकेशन किसी महत्वपूर्ण स्लॉट को डिस्पोजेबल के रूप में चिह्नित न कर सके।
3. आइडल टाइमआउट का सही उपयोग करें
PostgreSQL 18 का idle_replication_slot_timeout ऐसे स्लॉट को अमान्य कर देता है जिसका उपयोग कॉन्फ़िगर की गई अवधि से अधिक समय तक रेप्लिकेशन कनेक्शन द्वारा नहीं किया गया है; शून्य इसे अक्षम करता है। इनवैलिडेशन चेकपॉइंट पर ट्रिगर होता है, इसलिए वास्तविक समय सीमा (threshold) से अधिक हो सकता है। यह सेटिंग सर्वर-स्तरीय है और प्रति-स्लॉट व्यावसायिक वर्गीकरण की जगह नहीं लेती है।
4. ऑब्जर्वेबिलिटी और अलर्ट का निर्माण करें
स्लॉट प्रकार, डेटाबेस, restart_lsn, सक्रिय स्थिति, इनवैलिडेशन कारण और फेलओवर या सिंक स्थिति के लिए नियमित रूप से pg_replication_slots पढ़ें। बनाए रखे गए WAL बाइट्स और सबसे पुराने स्लॉट की आयु की गणना करें। विकास दर, डिस्क हेडरूम, आइडल अवधि और आसन्न इनवैलिडेशन पर अलर्ट करें, जिसमें स्वामी और रिकवरी रनबुक शामिल हों।
5. चेकपॉइंट और रेस कंडीशंस को संभालें
टाइमआउट मूल्यांकन एक चेकपॉइंट के दौरान चलता है, इसलिए कॉन्फ़िगर की गई सीमा एक सटीक समय सीमा नहीं है। एक कंज्यूमर सीमा के करीब फिर से कनेक्ट हो सकता है; अंतिम उपयोग का समय, चेकपॉइंट समय और अंतिम इनवैलिडेशन कारण रिकॉर्ड करें। नीति बदलने या स्लॉट हटाने से पहले, समान नाम के निर्माण, स्टैंडबाय सिंक्रोनाइज़ेशन, या इन-फ़्लाइट सब्सक्रिप्शन रिकवरी की जांच करें।
6. रिकवरी डिज़ाइन करें
इनवैलिडेशन के बाद, एक कंज्यूमर यह मान नहीं सकता कि उसकी पुरानी सीमा अभी भी उपलब्ध है। यदि डाउनटाइम डेटा हानि स्वीकार्य है, तो एक नया स्लॉट बनाएं और प्रारंभिक स्नैपशॉट लें। यदि हानि अस्वीकार्य है, तो बैकअप या बनाए रखे गए WAL से पुनर्स्थापित करें और सब्सक्रिप्शन को फिर से बनाएं। पुराने स्लॉट, डेटा सीमा, स्नैपशॉट समय और सत्यापन साक्ष्य को रिकॉर्ड करें।
7. क्षमता और परिवर्तन नियंत्रण को लिंक करें
जब WAL डायरेक्टरी अपनी सीमा के करीब पहुंच जाए, तो कम प्राथमिकता वाले बैकफ़िल को रोकें, WAL-उत्पादक बैच कार्य को सीमित करें, और प्राइमरी की उपलब्धता की रक्षा करें; किसी अज्ञात स्लॉट को न हटाएं। टाइमआउट परिवर्तनों को चरणों में रोल आउट करें, WAL वृद्धि, चेकपॉइंट्स, रेप्लिकेशन लैग और कंज्यूमर त्रुटियों का निरीक्षण करें, फिर नीति को समायोजित करें।
एक मजबूत उत्तर का उदाहरण
मैं स्वामियों के साथ एक स्लॉट कैटलॉग बनाए रखूंगा और स्लॉट्स को महत्वपूर्ण, पुनर्प्राप्ति योग्य या अस्थायी के रूप में वर्गीकृत करूंगा। पुनर्प्राप्ति योग्य और अस्थायी स्लॉट्स को आइडल टाइमआउट मिलता है; महत्वपूर्ण स्लॉट केवल अलर्ट करते हैं। चूंकि इनवैलिडेशन चेकपॉइंट के दौरान होता है, इसलिए मॉनिटरिंग चेकपॉइंट समय और वास्तविक कारण को रिकॉर्ड करती है। दैनिक रिपोर्ट बनाए रखे गए WAL, आइडल अवधि और डिस्क जोखिम की गणना करती हैं; थ्रेशोल्ड बैकफ़िल को रोकते हैं और स्वामियों को सूचित करते हैं। इनवैलिडेशन के बाद, रिकवरी पथ डेटा-लॉस अनुबंध के अनुसार री-स्नैपशॉट, बैकअप रीस्टोर या अनुमोदित रीबिल्ड चुनता है, जिसमें प्रत्येक क्रिया का ऑडिट किया जाता है।
सामान्य गलतियां
- यह मान लेना कि स्लॉट ठीक टाइमआउट समाप्त होने पर अमान्य हो जाता है और चेकपॉइंट्स को अनदेखा करना।
- प्रत्येक स्लॉट पर एक छोटा टाइमआउट लागू करना और डिजास्टर रिकवरी या ऑडिट स्लॉट को हटा देना।
restart_lsnसे बनाए रखे गए WAL की गणना करने के बजाय केवलactiveको देखना।- यह तय किए बिना कंज्यूमर को फिर से कनेक्ट करना कि डेटा या स्नैपशॉट सीमाएं खो गई थीं या नहीं।
- डिस्क घटना के दौरान किसी अज्ञात स्लॉट को हटाना और लाइव रेप्लिकेशन पथ को तोड़ना।
- कोई स्वामी, संरक्षित सूची या निष्पादन योग्य रिकवरी रनबुक न होना।
फॉलो-अप प्रश्न और उत्तर
idle_replication_slot_timeout कब प्रभावी होता है?
किसी स्लॉट के रेप्लिकेशन कनेक्शन द्वारा सेटिंग से अधिक समय तक अप्रयुक्त रहने के बाद, बाद के चेकपॉइंट के दौरान इनवैलिडेशन ट्रिगर होता है, इसलिए इसमें देरी हो सकती है।
क्या फिजिकल स्लॉट्स भी स्वचालित रूप से समाप्त होने चाहिए?
यह डिजास्टर-रिकवरी अनुबंध पर निर्भर करता है। स्टैंडबाय द्वारा एक फिजिकल स्लॉट की आवश्यकता हो सकती है; स्वचालित इनवैलिडेशन की अनुमति देने से पहले किसी अन्य सुरक्षा तंत्र की पुष्टि करें।
आप एक स्लॉट द्वारा बनाए रखे गए WAL की गणना कैसे करते हैं?
वर्तमान WAL स्थिति की तुलना स्लॉट के restart_lsn से करें, फिर प्रति स्लॉट सबसे पुरानी स्थिति, विकास दर और डिस्क हेडरूम को एकत्रित करें। अकेले active स्थान जोखिम का वर्णन नहीं करता है।
क्या कोई कंज्यूमर वापस लौटने के बाद फिर से शुरू कर सकता है?
केवल तभी जब आवश्यक WAL अभी भी मौजूद हो और स्लॉट मान्य बना रहे। इनवैलिडेशन या WAL हटाने के बाद, री-स्नैपशॉट, बैकअप रीस्टोर, या एक स्पष्ट डेटा गैप की आवश्यकता होती है।
आप अस्थायी बैकफ़िल स्लॉट लीक को कैसे रोकते हैं?
निर्माण के समय समाप्ति और स्वामी को रिकॉर्ड करें, अलग से अलर्ट करें, इनवैलिडेशन से पहले पुष्टि स्थिति में ले जाएं, और सत्यापित करें कि WAL रीसाइक्लिंग बाद में पुनर्प्राप्त हो जाती है।