प्रश्न
एक प्रोडक्शन PostgreSQL टेबल को एक नए CHECK या फॉरेन-की कंस्ट्रेंट की आवश्यकता है। मौजूदा पंक्तियाँ इसका उल्लंघन कर सकती हैं, और व्यवसाय लंबे समय तक राइट ब्लॉक को सहन नहीं कर सकता। उल्लंघनों को खोजने, NOT VALID कंस्ट्रेंट जोड़ने, ऐतिहासिक पंक्तियों की मरम्मत करने और VALIDATE CONSTRAINT चलाने के पूरे फ्लो को डिज़ाइन करें। इसमें लॉक्स, कॉनक्रेन्सी, मॉनिटरिंग और विफलता से निपटने के तरीके शामिल करें।
साक्षात्कारकर्ता क्या जांच रहा है
- क्या आप किसी कंस्ट्रेंट को जोड़ने के लॉक व्यवहार और बाद के वैलिडेशन स्कैन के बीच अंतर समझते हैं।
- क्या आप जानते हैं कि
NOT VALIDपुरानी पंक्तियों की स्कैनिंग को छोड़ देता है जबकि नए इंसर्ट और अपडेट की जांच अभी भी की जाती है। - क्या आप एक ब्लॉकिंग DDL जारी करने के बजाय रिपेयर, वैलिडेशन और एप्लिकेशन रोलआउट का समन्वय करते हैं।
- क्या कंस्ट्रेंट स्थिति वैलिडेशन विफलताओं, लंबे ट्रांजेक्शनों और रोलबैक के दौरान दृश्यमान और पुनर्प्राप्त करने योग्य रहती है।
आदर्श उत्तर
उल्लंघन करने वाली पंक्तियों, इंडेक्स उपलब्धता और लंबे ट्रांजेक्शनों का अनुमान लगाने के लिए रीड-ओनली क्वेरीज़ से शुरुआत करें। एक नियंत्रित विंडो के दौरान, ADD CONSTRAINT ... NOT VALID चलाएं। यह मौजूदा पंक्तियों को स्कैन नहीं करता है, लेकिन यह बाद के इंसर्ट और अपडेट की तुरंत जांच करता है; ऐतिहासिक पंक्तियाँ अभी भी नियम का उल्लंघन कर सकती हैं, इसलिए स्थिति स्पष्ट रूप से वैलिडेशन लंबित रहती है।
कमिट सीमाओं और प्रगति रिकॉर्ड के साथ सीमित बैचों में ऐतिहासिक पंक्तियों की मरम्मत करें। मरम्मत तर्क एप्लिकेशन नियम से मेल खाना चाहिए, इसलिए आवश्यकता पड़ने पर पहले संगत कोड तैनात करें। फिर लॉक प्रतीक्षा, स्कैन अवधि और डेटाबेस लोड पर नज़र रखते हुए VALIDATE CONSTRAINT चलाएं। एक सफल वैलिडेशन कैटलॉग कंस्ट्रेंट को मान्य चिह्नित करता है और माइग्रेशन को पूरा करता है।
फॉरेन की के लिए, संदर्भित कॉलमों पर एक उपयुक्त विशिष्टता (uniqueness) कंस्ट्रेंट सत्यापित करें और समवर्ती राइट्स और डिलीट्स का आकलन करें। यदि वैलिडेशन विफल हो जाता है, तो नए राइट्स की सुरक्षा के लिए NOT VALID कंस्ट्रेंट बनाए रखें, शेष पंक्तियों की मरम्मत करें और पुनः प्रयास करें। इसे केवल तभी हटाएं जब आवश्यकता वास्तव में हटा दी गई हो।
माइग्रेशन फ्लो
-- 1. Record violations and create repair work
SELECT count(*) FROM orders WHERE total < 0;
-- 2. Add the constraint without scanning historical rows
ALTER TABLE orders
ADD CONSTRAINT orders_total_nonnegative
CHECK (total >= 0) NOT VALID;
-- 3. Repair in batches, then validate
ALTER TABLE orders
VALIDATE CONSTRAINT orders_total_nonnegative;माइग्रेशन टूल को कंस्ट्रेंट नाम, बैच कर्सर, प्रारंभ और समाप्ति समय, वैलिडेशन परिणाम और ऑपरेटर को संग्रहीत करना चाहिए। रोलआउट से पहले, उसी नियम के विरुद्ध प्रत्येक एप्लिकेशन राइट पाथ की जांच करें ताकि रिपेयर जॉब और बिजनेस लॉजिक एक दूसरे को ओवरराइट न कर सकें।
NOT VALID का मूल्य एक महंगे ऐतिहासिक स्कैन को ऐड-कंस्ट्रेंट चरण से अलग करना है; वैलिडेशन अभी भी टेबल को स्कैन करता है और प्रलेखित लॉक लेता है, इसलिए यह पूरी तरह मुफ़्त नहीं है। लंबे ट्रांजेक्शनों और रेप्लिकेशन लैग की जांच करें, एक स्टेटमेंट टाइमआउट और लॉक-वेट अलर्ट सेट करें, और नियंत्रित विंडो में वैलिडेशन चलाएं।
वैलिडेशन के दौरान नए ट्रांजेक्शनों की जांच की जाती है, जबकि ऐतिहासिक मरम्मत को व्यावसायिक अपडेट को ओवरराइट करने से बचना चाहिए। बैचों के लिए स्थिर इंडेक्स रेंज और छोटे ट्रांजेक्शनों का उपयोग करें। FOR UPDATE SKIP LOCKED उपयुक्त होने पर काम का दावा कर सकता है, लेकिन छोड़ी गई पंक्तियों से प्रगति मेट्रिक्स को पूर्ण नहीं दिखना चाहिए।
सामान्य गलतियाँ
- यह मान लेना कि
NOT VALIDकंस्ट्रेंट को अक्षम कर देता है और नए अमान्य राइट्स की अनुमति देता है। - लंबे ट्रांजेक्शनों, लॉक प्रतीक्षाओं और रेप्लिकेशन क्षमता की जांच किए बिना
VALIDATE CONSTRAINTचलाना। - हर ऐतिहासिक पंक्ति को एक बड़े ट्रांजेक्शन में सुधारना, जिससे ब्लोट, लंबे लॉक और एक कठिन रोलबैक की स्थिति बने।
- फॉरेन की द्वारा आवश्यक संदर्भित इंडेक्स और डिलीट पाथ की अनदेखी करते हुए CHECK को ठीक करना।
- विफल कंस्ट्रेंट को हटा (drop) देना और नए राइट्स के लिए सुरक्षा तथा बाद के सुधार पथ को खो देना।
विफलता से निपटना और रोलबैक
स्पष्ट स्थितियों का उपयोग करें जैसे कि planned, not_valid, backfilling, validating, validated, और aborted। प्रत्येक संक्रमण को एक माइग्रेशन टेबल और ऑडिट लॉग में बनाए रखें। जब वैलिडेशन में उल्लंघन मिलते हैं, तो कंस्ट्रेंट नाम और संशोधित कुंजी नमूने रिकॉर्ड करें, वैलिडेशन को रोकें, और कंस्ट्रेंट को बनाए रखें; मरम्मत के बाद, रिकॉर्ड की गई प्रगति से फिर से शुरू करें।
यदि किसी एप्लिकेशन रिलीज़ को रोल बैक करना पड़ता है, तो संगतता कोड को अभी भी पुरानी पंक्तियों और नए कंस्ट्रेंट दोनों को संभालना चाहिए। NOT VALID कंस्ट्रेंट को हटाना अंतिम उपाय है और इसके लिए यह पुष्टि करना आवश्यक है कि नए राइट्स समस्या को फिर से उत्पन्न न कर सकें। किसी भी DROP CONSTRAINT के लिए अनुमोदन, बैकअप और फिर से जोड़ने की योजना होनी चाहिए।
ऑब्जर्वेबिलिटी
उल्लंघन गणना, मरम्मत दर, अनुमानित शेष समय, वैलिडेशन प्रगति, लॉक प्रतीक्षा, सबसे पुराने ट्रांजेक्शन की आयु, WAL वृद्धि और रेप्लिकेशन लैग की निगरानी करें। "एक नए राइट ने कंस्ट्रेंट का उल्लंघन किया" को "ऐतिहासिक पंक्तियों को मान्य नहीं किया गया है" से अलग करें; उन्हें अलग-अलग प्रतिक्रिया प्राथमिकताओं की आवश्यकता होती है।
वैलिडेशन के बाद, कैटलॉग स्थिति की पुष्टि करने के लिए pg_constraint.convalidated और कंस्ट्रेंट नाम को क्वेरी करें। परिणाम, क्वेरी प्लान और लोड विंडो को माइग्रेशन रिकॉर्ड में संग्रहीत करें। बाहरी रिपोर्टों में संशोधित कुंजियों और योगों का उपयोग होना चाहिए, लॉग में व्यावसायिक डेटा कभी नहीं होना चाहिए।
- PostgreSQL 17
ALTER TABLE:NOT VALIDऔरVALIDATE CONSTRAINTके लिए लॉक और कॉनक्रेन्सी सिमेंटिक्स। - वर्तमान PostgreSQL कंस्ट्रेंट दस्तावेज़ीकरण: CHECK, फॉरेन-की, और ऐतिहासिक-पंक्ति वैलिडेशन नियम।
- PostgreSQL 17
pg_constraint: कैटलॉग फ़ील्ड जैसेconvalidated।
फॉलो-अप प्रश्न
पुरानी पंक्तियाँ अमान्य रहने के बावजूद नए राइट्स की जाँच क्यों की जाती है?
NOT VALID कंस्ट्रेंट जोड़े जाने के समय पहले से मौजूद पंक्तियों के स्कैन को छोड़ देता है। परिभाषा अभी भी बाद के INSERT और UPDATE संचालन पर तुरंत लागू होती है, जो ऐतिहासिक बैकलॉग को बढ़ने से रोकती है।
क्या वैलिडेशन के दौरान राइट्स जारी रह सकते हैं?
वे जारी रह सकते हैं, लेकिन वैलिडेशन टेबल को पढ़ता है और प्रलेखित लॉक लेता है, इसलिए प्रतीक्षा समय और लोड को नियंत्रित किया जाना चाहिए। नई पंक्तियों की जांच की जाती है, और रिपेयर बैचों को एप्लिकेशन अपडेट को ओवरराइट करने से बचना चाहिए।
आप वैलिडेशन अवधि का अनुमान कैसे लगाते हैं?
मापे गए अनुमान या नमूने के लिए टेबल आकार, स्कैन प्लान, कैश व्यवहार, समवर्ती वर्कलोड और मेंटेनेंस विंडो का उपयोग करें। यह न मानें कि केवल पंक्ति संख्या रैखिक है; प्रोडक्शन से पहले टाइमआउट और रद्दीकरण नीतियां निर्धारित करें।
फॉरेन-की माइग्रेशन में क्या विशेष है?
संदर्भित कॉलमों पर विशिष्टता और अनुक्रमण (indexing) सत्यापित करें और स्थिर विलोपन सिमेंटिक्स को परिभाषित करें। वैलिडेशन के दौरान, समवर्ती डिलीट्स, अपडेट्स और लॉक विवादों के साथ मौजूदा चाइल्ड पंक्तियों पर नज़र रखें।
आपको कंस्ट्रेंट को कब छोड़ना और हटाना चाहिए?
केवल तब जब आवश्यकता वापस ले ली गई हो या गलत तरीके से डिज़ाइन की गई हो और एक वैकल्पिक सुरक्षा मौजूद हो। केवल वैलिडेशन विफलता इसे हटाने का कारण नहीं है; NOT VALID को बनाए रखने से नए डेटा की सुरक्षा जारी रहती है और सुधार पथ सुरक्षित रहता है।