डेटा इंजीनियरिंग इंटरव्यू: SQLite के WAL-reset करप्शन जोखिम को सुरक्षित रूप से संभालना

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

एक डेस्कटॉप सिंक सेवा WAL मोड में कई प्रोसेस से एक ही SQLite फ़ाइल खोलती है। टीम को पता चलता है कि पुराने वर्ज़न में WAL-reset बग हो सकता है और वह गलत डेटा पढ़ने की सुरक्षा, अपग्रेड के दौरान समवर्ती (concurrent) राइट्स, या डाउनस्ट्रीम में क्षतिग्रस्त कॉपी सिंक होने को लेकर चिंतित है। वर्ज़न इन्वेंट्री, जोखिम मूल्यांकन, अपग्रेड, इंटीग्रिटी सत्यापन, बैकअप रिकवरी और रोलबैक डिज़ाइन करें, जिसमें मल्टी-प्रोसेस एक्सेस कंट्रोल भी शामिल हों।

इंटरव्यूअर क्या टेस्ट करता है

• प्रभावित वर्ज़न रेंज को उन स्थितियों से अलग करना जो बग को ट्रिगर कर सकती हैं।
• आधिकारिक फिक्स्ड और बैकपोर्टेड वर्ज़न से एक अपग्रेड मैट्रिक्स बनाना।
• सुसंगत बैकअप, सत्यापन, आइसोलेशन और रिकवरी चरणों को सही क्रम में व्यवस्थित करना।
• PRAGMA integrity_check को व्यावसायिक शुद्धता (business correctness) मानने के बजाय इसकी सीमाओं की व्याख्या करना।
• मल्टी-प्रोसेस राइट्स, चेकपॉइंट्स, फ़ाइल कॉपी और सिंक के दुष्प्रभावों को संभालना।

स्पष्ट करने हेतु प्रश्न

1. कौन से सटीक SQLite वर्ज़न, बिल्ड विकल्प, ऑपरेटिंग सिस्टम और जर्नल मोड डिप्लॉय किए गए हैं?
2. क्या दो या अधिक प्रोसेस या थ्रेड एक ही फ़ाइल में राइट कर रहे हैं या चेकपॉइंटिंग कर रहे हैं?
3. कौन से सत्यापित बैकअप, रेप्लिकस और अंतिम-सफल-जांच (last-successful-check) टाइमस्टैम्प मौजूद हैं?
4. क्या अपग्रेड राइट्स को कुछ समय के लिए रोक (freeze) सकता है और पुराने प्रोसेस को बाहर निकलने के लिए बाध्य कर सकता है?
5. क्या रिकवरी का लक्ष्य हालिया ट्रांजेक्शन का नुकसान, सर्वर पुनर्निर्माण, या सटीक पुनर्स्थापना (exact restoration) है?

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

मैं सबसे पहले वर्ज़न और रनटाइम मोड की इन्वेंट्री बनाऊँगा; एक प्रभावित वर्ज़न रेंज करप्शन को साबित नहीं करती है। SQLite 3.7.0 से 3.51.2 तक कुछ WAL परिदृश्यों में WAL-reset बग का दस्तावेजीकरण करता है, जिसे 3.51.3 और बाद के वर्ज़न में कुछ बैकपोर्टेड रिलीज़ के साथ ठीक किया गया है। अपग्रेड करने से पहले, राइट्स को रोकें (freeze करें), डेटाबेस और WAL/SHM साक्ष्य की कॉपी बनाएं, और एक सत्यापन बेसलाइन रिकॉर्ड करें। एक अलग (isolated) कॉपी को अपग्रेड करें, फिर स्ट्रक्चरल इंटीग्रिटी चेक्स, बिज़नेस-लेवल सैंपलिंग और सिंक कंसिस्टेंसी चेक्स चलाएं। गेट पास होने के बाद ही प्रोडक्शन फ़ाइल को स्विच करें, और एक रोलबैक कॉपी अपने पास रखें। दीर्घावधि में, मल्टी-प्रोसेस राइट्स को सीमित करें, चेकपॉइंट्स, लॉक विवादों और सत्यापन विफलताओं की निगरानी करें, और रिकवरी अभ्यासों को रिलीज़ गेट्स का हिस्सा बनाएं।

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

1. एक प्रभाव मैट्रिक्स (impact matrix) बनाएं

SQLite की आधिकारिक सामग्री संभावित बग रेंज को 3.7.0 से 3.51.2 तक रखती है, जिसमें 3.51.3 और बाद के वर्ज़न में सुधार है और 3.44.6 व 3.50.7 में बैकपोर्ट उपलब्ध हैं। जोखिम के लिए WAL मोड, एक फ़ाइल में कई कनेक्शन, और एक छोटे अंतराल में राइट्स या चेकपॉइंट्स का इंटरलीव होना भी आवश्यक है। प्रत्येक क्लाइंट के SQLite वर्ज़न, WAL स्थिति, कनेक्शन संख्या, प्रोसेस मॉडल और फ़ाइल स्थान को रिकॉर्ड करें, फिर "प्रभावित वर्ज़न और ट्रिगर स्थितियां मौजूद हैं" के रूप में वर्गीकृत करें।

version/mode -> WAL enabled -> multi-connection/process -> concurrent write/checkpoint
      |             |                    |                         |
      +-- upgrade gate ------------------+----------> isolate, verify, rehearse recovery

2. राइट्स को रोकें (Freeze करें) और साक्ष्य सुरक्षित रखें

नए राइट्स को रोकें और एप्लिकेशन को कनेक्शन सामान्य रूप से बंद करने दें। यदि पुराने प्रोसेस अभी भी सक्रिय हो सकते हैं, तो डेटाबेस को बदलें या कॉपी न करें। मूल डेटाबेस, समान-डायरेक्टरी वाली WAL/SHM फ़ाइलें, वर्ज़न डेटा, नवीनतम बैकअप और सत्यापन लॉग को सुरक्षित रखें। केवल एक स्थिर स्थिति से ही कॉपी करें; बदलता हुआ WAL कोई स्टैटिक स्नैपशॉट नहीं है।

3. आइसोलेशन में अपग्रेड और सत्यापन करें

एक फिक्स्ड वर्ज़न के साथ एक कॉपी खोलें। पहले SQLite-लेवल इंटीग्रिटी चेक्स चलाएं, फिर पंक्ति गणना (row counts), मुख्य इंडेक्स, फॉरेन कीज़, सिंक कर्सर और हालिया ट्रांजेक्शन के लिए एप्लिकेशन चेक्स चलाएं। integrity_check स्ट्रक्चरल समस्याओं को ढूंढ सकता है लेकिन डोमेन सिमेंटिक्स, रिमोट रेप्लिकस समानता, या अनकमिटेड कार्य की पूर्णता को साबित नहीं कर सकता है। परिणामों को कॉपी हैश और टूल वर्ज़न से जोड़ें।

4. स्विच करें, रोल बैक करें और पुनर्प्राप्त (recover) करें

गेट पास होने के बाद, एटॉमिक रूप से फ़ाइल पाथ या वर्ज़न वाली डायरेक्टरी को स्विच करें और पुरानी कॉपी को केवल-पढ़ने योग्य (read-only) रखें। यदि स्टार्टअप पर सत्यापन विफलता, सिंक विवाद, या व्यावसायिक कमी का पता चलता है, तो नए राइट्स को रोकें, वापस स्विच करें या एक विश्वसनीय बैकअप से पुनर्निर्माण करें, और फिर वृद्धिशील (incrementally) रूप से पुनः सिंक करें। साक्ष्य सुरक्षित करने से पहले संदिग्ध क्षतिग्रस्त फ़ाइल पर VACUUM, बल्क रिपेयर या प्रतियों को ओवरराइट न करें।

5. मल्टी-प्रोसेस राइट्स और चेकपॉइंट्स को नियंत्रित करें

एक फ़ाइल के लिए एक ही राइटर प्रोसेस को प्राथमिकता दें और एक कतार के माध्यम से राइट ट्रांजेक्शन को क्रमबद्ध (serialize) करें; अन्य प्रोसेस नियंत्रित रीड कनेक्शन का उपयोग करें। परिभाषित करें कि चेकपॉइंट्स को कौन ट्रिगर करता है, उनका टाइमआउट क्या है, और विफलता अलर्ट कैसे मिलते हैं ताकि कई घटक एक साथ चेकपॉइंटिंग न करें। यदि मल्टी-प्रोसेस एक्सेस अपरिहार्य है, तो कनेक्शन लाइफसाइकिल, लॉक प्रतीक्षा, चेकपॉइंट परिणाम और प्रोसेस वर्ज़न रिकॉर्ड करें, और इंटरलीव्ड राइट्स और चेकपॉइंट्स का स्ट्रेस-टेस्ट करें।

6. निगरानी करें और रिकवरी का अभ्यास करें

रिलीज़ के बाद, SQLite वर्ज़न कवरेज, WAL वृद्धि, चेकपॉइंट लेटेंसी, लॉक विवाद, इंटीग्रिटी विफलताएं, सिंक पुनः प्रयास (retries) और रिकवरी समय की निगरानी करें। सैनिटाइज़ की गई प्रतियों पर "फ्रीज—बैकअप—वेरिफाई—स्विच—रोलबैक" का अभ्यास करें और सत्यापित करें कि पुराने क्लाइंट पुराने-वर्ज़न वाले डेटाबेस को फिर से न खोल सकें। केवल यह कहने के बजाय कि "बैकअप मौजूद हैं", रिकवरी लक्ष्यों को व्यावसायिक RPO और RTO के रूप में व्यक्त करें।

मॉडल उत्तर

मैं एक प्रभाव मैट्रिक्स के साथ शुरुआत करूँगा: क्या SQLite 3.7.0–3.51.2 में है, क्या WAL सक्षम है, क्या कई कनेक्शन फ़ाइल साझा करते हैं, और क्या राइट्स और चेकपॉइंट्स ओवरलैप हो सकते हैं। सीमा में होने का अर्थ है अपग्रेड करना और सत्यापित करना; यह करप्शन को साबित नहीं करता है। राइट्स को फ्रीज करें, पुष्टि करें कि पुराने प्रोसेस समाप्त हो गए हैं, डेटाबेस, WAL/SHM, बैकअप, वर्ज़न और हैश को सुरक्षित रखें, और एक अलग कॉपी को 3.51.3 या एक स्वीकार्य बैकपोर्ट में अपग्रेड करें।

सत्यापन के तीन स्तर हैं: स्ट्रक्चर के लिए PRAGMA integrity_check, प्रमुख डेटा और इंडेक्स के लिए एप्लिकेशन सैंपलिंग, और स्थानीय बनाम रिमोट कर्सर के लिए सिंक चेक्स। गेट पास होने के बाद एटॉमिक रूप से स्विच करें और पुरानी कॉपी को केवल-पढ़ने योग्य रखें। यदि चेक या व्यावसायिक इनवेरिएंट्स विफल होते हैं, तो राइट्स रोकें, एक विश्वसनीय कॉपी पुनर्स्थापित करें, और इंक्रीमेंटल सिंक का पुनर्निर्माण करें। दीर्घावधि में, राइट्स को एक प्रोसेस में केंद्रीकृत करें, सक्रिय चेकपॉइंट्स को सीमित करें, लॉक विवादों और सत्यापन विफलताओं की निगरानी करें, और रिकवरी का अभ्यास करें।

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

• केवल इसलिए डेटाबेस को क्षतिग्रस्त घोषित करना क्योंकि एक पुराना वर्ज़न डिप्लॉय किया गया है।
• राइट्स को फ्रीज किए बिना या WAL/SHM और रोलबैक प्रतियों को सुरक्षित रखे बिना बायनेरीज़ को अपग्रेड करना।
• एक पास हुए integrity_check को पूर्ण व्यावसायिक शुद्धता का प्रमाण मानना।
• साक्ष्य सुरक्षित करने से पहले संदिग्ध क्षतिग्रस्त फ़ाइल पर VACUUM चलाना या उसे ओवरराइट करना।
• विवाद और टाइमआउट मेट्रिक्स के बिना कई प्रोसेस को स्वतंत्र रूप से चेकपॉइंट करने की अनुमति देना।
• बैकअप स्थिरता, RPO, RTO, या रिकवरी अभ्यास के बिना केवल यह कहना कि "हम नियमित रूप से बैकअप लेते हैं"।

अनुवर्ती प्रश्न और उत्तर

यदि वर्ज़न प्रभावित है लेकिन कोई विसंगति दिखाई नहीं दे रही है, तो क्या हम अपग्रेड छोड़ सकते हैं?

नहीं। अल्पकालिक जोखिम का आकलन करने के लिए ट्रिगर स्थितियों का उपयोग करें और फिक्स्ड वर्ज़न को शेड्यूल करें; देखी गई विफलता की अनुपस्थिति एक संकीर्ण रेस कंडीशन (narrow race) को खारिज नहीं करती है।

PRAGMA integrity_check पास होने के बाद बिज़नेस चेक्स क्यों करें?

यह मुख्य रूप से डेटाबेस स्ट्रक्चर और चयनित बाधाओं (constraints) की जांच करता है। यह सिंक कर्सर, डोमेन इनवेरिएंट्स, रिमोट समानता, या हालिया ट्रांजेक्शन की पूर्णता को मान्य नहीं करता है, इसलिए एप्लिकेशन सैंपलिंग और रेप्लिका तुलना आवश्यक बनी रहती है।

यदि मल्टी-प्रोसेस एक्सेस को तुरंत फिर से डिज़ाइन नहीं किया जा सकता है तो अस्थायी उपाय क्या है?

SQLite वर्ज़न और स्टार्टअप सेटिंग्स को एकीकृत करें, अनियंत्रित सक्रिय चेकपॉइंट्स को प्रतिबंधित करें, राइट्स को क्रमबद्ध करें, और लॉक-विवाद टेलीमेट्री में सुधार करें। कैनरी बैचों को छोटा करें और एक रीड-ओनली कॉपी रखें जिसे सिंगल-राइटर डिज़ाइन उपलब्ध होने तक जल्दी से वापस स्विच किया जा सके।