डेटा इंजीनियरिंग इंटरव्यू: आप PostgreSQL 19 Beta 2 अपग्रेड मूल्यांकन के लिए गेट (शर्तें) कैसे निर्धारित करेंगे?

प्रॉम्प्ट और संदर्भ

एक SaaS टीम PostgreSQL 18 चलाती है और PostgreSQL 19 Beta 2 के बारे में शुरुआती साक्ष्य (evidence) चाहती है। इसके वर्कलोड में लॉन्ग ट्रांजेक्शन, लॉजिकल रेप्लिकेशन, एक्सटेंशन, बैकअप और पीक बैच जॉब शामिल हैं। एक ऐसा मूल्यांकन डिज़ाइन करें जो बीटा क्लस्टर पर प्रोडक्शन ट्रैफ़िक डाले बिना प्रतिनिधि साक्ष्यों का उपयोग करे। यदि परिणाम अस्थिर रहते हैं, तो आप प्रक्रिया को रोककर वर्तमान वर्शन पर वापस कैसे लौटेंगे?

PostgreSQL प्रोजेक्ट बीटा को एक फीचर प्रीव्यू के रूप में वर्णित करता है जिसके विवरण अंतिम रिलीज़ से पहले बदल सकते हैं, और इसे प्रोडक्शन में चलाने की सलाह नहीं देता है। आधिकारिक pg_upgrade दस्तावेज़ीकरण कहता है कि यह बीटा स्नैपशॉट सहित वर्तमान प्रमुख रिलीज़ में अपग्रेड कर सकता है, लेकिन बाहरी-मॉड्यूल (external-module) बाइनरी कम्पैटिबिलिटी को टूल द्वारा पूरी तरह से जाँचा नहीं जा सकता है। यह इंटरव्यू साक्ष्य श्रृंखला (chain of evidence) और अपग्रेड गवर्नेंस का परीक्षण करता है।

इंटरव्यूअर क्या मूल्यांकन कर रहा है

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

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

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

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

“मैं बीटा को एक आइसोलेटेड प्रयोग मानूँगा, न कि कोई प्रोडक्शन प्रतिबद्धता। सबसे पहले मैं एक PostgreSQL 18 बेसलाइन फ़्रीज़ करूँगा, डी-आइडेंटिफाई किए गए डेटा को कॉपी करूँगा और प्रतिनिधि वर्कलोड्स को रीप्ले करूँगा। एक अलग क्लस्टर में मैं pg_upgrade --check, एक्सटेंशन और ड्राइवर जांच, बैकअप-रिस्टोर ड्रिल और विफलता परीक्षण चलाऊँगा, फिर लेटेंसी, थ्रूपुट, लॉक वेट्स, रेप्लिकेशन लैग, एरर रेट और रिसोर्स उपयोग की तुलना करूँगा। प्रत्येक सिग्नल के लिए एक पास थ्रेशोल्ड और एक स्टॉप थ्रेशोल्ड होगा; डेटा करप्शन, विफल रिकवरी या कम्पैटिबिलिटी ब्लॉकर का अर्थ तत्काल बाहर निकलना (exit) होगा। केवल एक अंतिम रिलीज़, बार-बार परखे गए साक्ष्य और एक स्पष्ट रोलबैक पाथ ही नियंत्रित कैनरी (canary) को सही ठहरा सकते हैं।”

चरण-दर-चरण विस्तृत उत्तर

1. लक्ष्यों को गलत साबित करने योग्य परिकल्पनाओं (falsifiable hypotheses) में बदलें

“नया वर्शन तेज़ होना चाहिए” से शुरुआत न करें। ऐसी परिकल्पनाएँ तैयार करें जैसे बैच p95 में 10% की कमी, रिकवरी का समय बेसलाइन से बदतर न होना, या प्रत्येक मौजूदा एक्सटेंशन का टारगेट वर्शन पर कंपाइल होना और रिग्रेशन पास करना। प्रत्येक परिकल्पना के लिए एक डेटा स्रोत, माप विंडो (measurement window) और विफलता की परिभाषा की आवश्यकता होती है ताकि केवल सफल नमूनों को चुनिंदा रूप से न चुना जा सके।

2. एक पुनरुत्पादित बेसलाइन फ़्रीज़ करें

PostgreSQL 18 पर, समान हार्डवेयर, सेटिंग्स, डेटा आकार और वर्कलोड के तहत लेटेंसी पर्सेंटाइल, थ्रूपुट, CPU, मेमोरी, IO, लॉक वेट्स, WAL वॉल्यूम, रेप्लिकेशन लैग, एरर रेट और रिकवरी टाइम रिकॉर्ड करें। क्वेरी प्लान और स्टैटिस्टिक्स वर्शन कैप्चर करें, और क्लाइंट-ड्राइवर व पूल सेटिंग्स को स्थिर रखें। बिना बेसलाइन के, किसी बदलाव को प्रयोग के बजाय वर्शन का परिणाम नहीं माना जा सकता।

3. बीटा क्लस्टर और डेटा पाथ को आइसोलेट करें

अलग नेटवर्क, क्रेडेंशियल्स, बैकअप बकेट और मॉनिटरिंग नेमस्पेस का उपयोग करें। स्नैपशॉट, लॉजिकल-रेप्लिकेट कॉपी या रीप्ले करने योग्य लॉग के माध्यम से आयात करने से पहले प्रोडक्शन डेटा को डी-आइडेंटिफाई करें। बीटा को प्रोडक्शन प्राइमरी पर लिखने, फ़ेलओवर VIP साझा करने या एकमात्र बैकअप स्रोत बनने की अनुमति न दें। प्रयोग की सुरक्षा के लिए दर-सीमित (rate-limiting) करते हुए ऑर्डरिंग, कॉन्करेंसी और असामान्य ट्रैफ़िक को बनाए रखें।

4. पहले अपग्रेड और कम्पैटिबिलिटी जांच चलाएं

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

pg_upgrade --check \
  --old-bindir=/opt/postgresql/18/bin \
  --new-bindir=/opt/postgresql/19/bin \
  --old-datadir=/data/pg18 \
  --new-datadir=/data/pg19

5. वर्कलोड्स को लेयर्स (परतों) में रीप्ले करें

SQL कम्पैटिबिलिटी, माइग्रेशन स्क्रिप्ट और ORM टेस्ट से शुरुआत करें। फिर ऑफ़लाइन बैच, मिक्स्ड रीड और राइट, लॉन्ग ट्रांजेक्शन, लॉजिकल रेप्लिकेशन और बैकअप रिस्टोर चलाएं। केवल औसत के बजाय p50, p95, p99 और टेल एरर्स (tail errors) की तुलना करें। क्वेरी-प्लान बदलावों, लॉक वेट्स, VACUUM, WAL, रेप्लिकेशन स्लॉट और एक्सटेंशन लॉग पर अलर्ट सेट करें; किसी महत्वपूर्ण-पाथ रिग्रेशन को समग्र औसत के पीछे न छिपाएं।

6. गेट्स, रोलबैक और निर्णय रिकॉर्ड सेट करें

जारी रखने, रोकने (pause) और बाहर निकलने (exit) के परिणामों को पहले से परिभाषित करें। डेटा-सत्यापन विफलता, एक विफल रिस्टोर ड्रिल, एक अनुपलब्ध महत्वपूर्ण एक्सटेंशन, या बजट से अधिक एरर रेट और रेप्लिकेशन लैग का अर्थ बाहर निकलना है; कैलेंडर की तारीखों को पूरा करने के लिए गेट्स में ढील न दें। एक बूट करने योग्य PostgreSQL 18 बैकअप, रोलबैक स्क्रिप्ट, डेटा-अंतर रिपोर्ट, वर्शन-नियंत्रित सेटिंग्स और ज्ञात समस्याओं की सूची बनाए रखें। बीटा परिणाम अगली परीक्षण योजना को सूचित करते हैं, अंतिम रिलीज़ के बारे में कोई वादा नहीं करते।

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

मैं पहले परिकल्पनाओं और अस्वीकार्य जोखिमों को बताऊंगा, फिर PostgreSQL 18 बेसलाइन पर हार्डवेयर, सेटिंग्स, डेटा आकार और वर्कलोड को फ़्रीज़ करूँगा। बीटा क्लस्टर डी-आइडेंटिफाई डेटा, अलग नेटवर्किंग और अलग बैकअप का उपयोग करेगा। मैं pg_upgrade --check चलाऊँगा, फिर एक्सटेंशन, ड्राइवर, टेबलस्पेस और क्लाइंट्स को सत्यापित करूँगा। उसके बाद मैं p95/p99, थ्रूपुट, लॉक वेट्स, WAL, रेप्लिकेशन लैग, एरर रेट और RTO की तुलना करते हुए SQL, बैच, लॉन्ग ट्रांजेक्शन, रेप्लिकेशन, विफलता रिकवरी और बैकअप रिस्टोर को रीप्ले करूँगा। प्रत्येक सिग्नल के पास और स्टॉप थ्रेशोल्ड होंगे; डेटा करप्शन, विफल रिकवरी, या एक महत्वपूर्ण कम्पैटिबिलिटी समस्या होने पर वर्शन-18 रोलबैक पाथ पर बाहर निकल जाएँगे। केवल एक अंतिम रिलीज़, बार-बार सफल रन और बिज़नेस ओनर की मंज़ूरी ही एक मॉनिटर किए जाने वाले, रोके जा सकने वाले कम जोखिम वाले कैनरी की अनुमति देगी।

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

• बीटा को प्रोडक्शन कैंडिडेट मानना → विवरण अभी भी बदल सकते हैं → इसे आइसोलेटेड रखें और अंतिम रिलीज़ व बार-बार परखे गए साक्ष्यों की प्रतीक्षा करें।
• केवल pg_upgrade --check चलाना → टूल की जांच बिज़नेस व्यवहार या सभी बाहरी मॉड्यूल को कवर नहीं करती है → एक्सटेंशन, ड्राइवर, एप्लिकेशन और रिकवरी रिग्रेशन जोड़ें।
• केवल औसत लेटेंसी की तुलना करना → टेल रिग्रेशन छिप जाते हैं → p95/p99, एरर और लॉक वेट्स को ट्रैक करें।
• प्रोडक्शन राइट्स को सीधे रीप्ले करना → बीटा विफलता वास्तविक ट्रैफ़िक को प्रभावित कर सकती है → डी-आइडेंटिफाई की गई प्रतियों, अलग नेटवर्क और नियंत्रित रीप्ले का उपयोग करें।
• पहले से कोई स्टॉप कंडीशन परिभाषित न करना → शेड्यूल साक्ष्यों पर भारी पड़ जाता है → परीक्षण से पहले एग्जिट गेट्स और निर्णय का स्वामित्व तय करें।

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

क्या pg_upgrade --check पास होने के तुरंत बाद स्विच किया जा सकता है?

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

PostgreSQL 18 बेसलाइन और रोलबैक पाथ को क्यों बनाए रखें?

बिना बेसलाइन के, वर्शन परिवर्तन को प्रयोग के शोर (noise) से अलग नहीं किया जा सकता है। एक बूट करने योग्य पुराने-वर्शन पाथ के बिना, एक विफल प्रयोग एक अनियंत्रित माइग्रेशन घटना बन जाता है।

आप केवल अनुकूल बीटा परिदृश्यों के परीक्षण से कैसे बचते हैं?

पीक ट्रैफ़िक, लॉन्ग ट्रांजेक्शन, असामान्य ट्रैफ़िक, रेप्लिकेशन और रिकवरी मामलों को पहले से चुनें। रीप्ले क्रम और डेटा आकार को स्थिर करें, और सफलताओं के साथ-साथ विफलताओं व टेल मेट्रिक्स को भी रिकॉर्ड करें।

आप एक्सटेंशन बाइनरी कम्पैटिबिलिटी को कैसे सत्यापित करते हैं?

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

मूल्यांकन प्रोडक्शन कैनरी में कब प्रवेश कर सकता है?

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