आप PostgreSQL इंडेक्स को ऑनलाइन सुरक्षित रूप से कैसे बनाते या फिर से बनाते (rebuild) हैं?

1. प्रश्न

एक orders टेबल लगातार राइट्स (writes) प्राप्त कर रही है, जबकि एक क्वेरी टीम कंपोजिट इंडेक्स का अनुरोध करती है। दूसरी टेबल में एक ऐसा इंडेक्स है जिसे ब्लोट (bloat) के कारण फिर से बनाने की आवश्यकता है। टेबल बड़ी हैं, विंडो ऑफ-पीक है, और सामान्य रीड्स और राइट्स को ब्लॉक नहीं किया जा सकता है। एक अवलोकनीय (observable), प्रतिवर्ती (reversible) ऑनलाइन योजना प्रदान करें।

2. बाधाएं और स्पष्टीकरण

PostgreSQL संस्करण, टेबल और इंडेक्स प्रकार, प्रतिकृति टोपोलॉजी (replication topology), डिस्क हेडरूम और राइट पीक की पुष्टि करें।
CREATE INDEX, CREATE INDEX CONCURRENTLY, और REINDEX CONCURRENTLY में अंतर स्पष्ट करें।
समवर्ती निर्माण (Concurrent builds) राइट-लॉक प्रभाव को कम करते हैं लेकिन एक से अधिक बार स्कैन करते हैं, CPU/IO का उपभोग करते हैं, और किसी ट्रांज़ैक्शन ब्लॉक के अंदर नहीं चल सकते हैं।
कार्यान्वयन से पहले स्वीकार्य निर्माण समय (build time), लॉक प्रतीक्षा (lock wait), विलंबता (latency) और क्लीनअप विंडो को परिभाषित करें।

3. मुख्य विचार

एक नियमित इंडेक्स निर्माण राइट्स को ब्लॉक कर सकता है। एक समवर्ती निर्माण इंसर्ट, अपडेट और डिलीट को जारी रखने की अनुमति देता है लेकिन इसमें अधिक समय लगता है और अधिक संसाधनों की खपत होती है। पहले यथार्थवादी पैमाने पर शैडो परिवेश (shadow environment) में लागत का अनुमान लगाएं; प्रोडक्शन में, lock_timeout सेट करें, statement_timeout को सीमित करें, और संसाधनों की निगरानी करें। निर्माण के बाद, प्लानर की पसंद, रोलबैक पथ और रेप्लिका निरंतरता को सत्यापित करें; एक सफल DDL कमांड एक सफल व्यावसायिक रोलआउट नहीं है।

4. संदर्भ प्रवाह

text

preflight:
  verify_version_replicas_disk_and_query_shape()
  estimate_scan_cost_on_shadow_copy()
  reserve_maintenance_window_and_abort_thresholds()

build:
  set lock_timeout = short
  set statement_timeout = bounded
  CREATE INDEX CONCURRENTLY idx_orders_customer_time
    ON orders (customer_id, created_at DESC)

verify:
  inspect_index_state_and_size()
  EXPLAIN (ANALYZE, BUFFERS) representative_queries()
  compare_write_latency_replica_lag_and_error_rate()

रीबिल्ड के लिए REINDEX CONCURRENTLY को प्राथमिकता दें। यदि कोई विफलता एक अमान्य अस्थायी इंडेक्स (invalid temporary index) छोड़ देती है, तो पुन: प्रयास करने से पहले दस्तावेज़ीकरण के अनुसार इसे पहचानें और साफ़ करें। परिनियोजन स्क्रिप्ट (Deployment scripts) को नामकरण, आइडमपोटेंसी (idempotency) और अलर्ट को ट्रैक करने योग्य बनाना चाहिए; एक सामान्य ट्रांज़ैक्शनल माइग्रेशन के अंदर समवर्ती DDL को न छिपाएं।

5. विफलता के मामले और समझौते (Trade-offs)

लंबे ट्रांज़ैक्शन, परस्पर विरोधी स्नैपशॉट या अपर्याप्त डिस्क के कारण समवर्ती निर्माण विफल हो सकता है। एक विफल ऑब्जेक्ट अमान्य रह सकता है और स्थान का उपभोग करना जारी रख सकता है। निर्माण के दौरान CPU, IO और WAL की वृद्धि सेवा को धीमा कर सकती है और रेप्लिका अंतराल (replica lag) को बढ़ा सकती है, इसलिए इसे थ्रॉटल करें या रोकें। यदि लागत अस्वीकार्य है, तो क्वेरी को ऑप्टिमाइज़ करें, टेबल को पार्टीशन करें, या एक ऑनलाइन माइग्रेशन टूल का उपयोग करें, लेकिन फिर भी इसके ट्रिगर्स, बैकफ़िल, कटओवर और रोलबैक व्यवहार को सत्यापित करें।

6. सत्यापन और अवलोकनीयता

इंडेक्स की स्थिति, आकार, निर्माण अवधि, लॉक प्रतीक्षा, WAL, CPU/IO और रेप्लिका अंतराल को रिकॉर्ड करें।
प्रतिनिधि प्रश्नों के लिए प्लान्स, स्कैन की गई पंक्तियों, p95/p99 विलंबता और राइट थ्रूपुट की तुलना करें।
लंबे ट्रांज़ैक्शन, अमान्य इंडेक्स, डुप्लिकेट इंडेक्स और बाधा निर्भरताओं (constraint dependencies) की जांच करें।
पुराने इंडेक्स को हटाने से पहले कई पूर्ण ट्रैफ़िक पीक की प्रतीक्षा करें, और एक रिकवरी स्क्रिप्ट रखें।

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

यह मान लेना कि CONCURRENTLY कोई लॉक नहीं लेता है और संक्षिप्त लॉक प्रतीक्षा तथा संसाधन विवाद की अनदेखी करना।
CREATE INDEX CONCURRENTLY को एक ट्रांज़ैक्शन ब्लॉक के अंदर रखना, जिससे यह तुरंत विफल हो जाता है।
अमान्य इंडेक्स, रेप्लिका अंतराल और वास्तविक क्वेरी प्लान के बजाय केवल DDL रिटर्न कोड की जांच करना।
डिस्क, WAL और लंबे ट्रांज़ैक्शन बजट के बिना एक विशाल टेबल का पुनर्निर्माण करना।

8. साक्षात्कार स्कोरिंग बिंदु

समवर्ती DDL सिमेंटिक्स में अंतर करता है

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

प्रोडक्शन प्रीफ़्लाइट जांच की योजना बनाता है

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

विफलता से रिकवरी को डिज़ाइन करता है

उम्मीदवार क्लीनअप, पुन: प्रयास और रोलबैक चरणों के साथ अमान्य इंडेक्स, टाइमआउट, डिस्क की कमी और रेप्लिका अंतराल को संभालता है।

व्यावसायिक मीट्रिक्स के साथ सत्यापित करता है

उम्मीदवार केवल DDL रिटर्न कोड पर भरोसा करने के बजाय प्लान्स, p95/p99, राइट लेटेंसी, WAL, लॉक प्रतीक्षा और रेप्लिका अंतराल की तुलना करता है।

आप PostgreSQL इंडेक्स को ऑनलाइन सुरक्षित रूप से कैसे बनाते या फिर से बनाते (rebuild) हैं?

प्रश्न