डेटाबेस का स्कीमा असल में कहाँ रहता है

यह सेवा जो कुछ करती है, वह सब वर्ज़न कंट्रोल में है। कम से कम कोड तो है। जिस डेटाबेस पर यह चलती है, उसमें 32 टेबल हैं, और उनमें से 15 की परिभाषा रिपॉज़िटरी में कहीं नहीं है — न कोई CREATE TABLE, न कोई स्कीमा फ़ाइल, कुछ भी नहीं। एक डंप सभी 32 टेबल उनकी पूरी संरचना के साथ रीस्टोर कर देता है; रिपॉज़िटरी में जो नहीं है, वह उस संरचना की एक दूसरी, स्वतंत्र कॉपी है।

ये आँकड़े लाइव डेटाबेस की तुलना रिपॉज़िटरी की 736 फ़ाइलों और 56,71,710 अक्षरों से करके निकले हैं। ये अनुमान नहीं हैं।

आधा स्कीमा कैसे गायब हो जाता है

यह लापरवाही नहीं है, और इसीलिए इसे लिखना ज़रूरी है। हर एक कदम अपने आप में समझदारी भरा था।

जो टेबल मौजूदा कोडबेस से पहले बनीं, उन्हें कभी लिखा नहीं गया, क्योंकि उस समय वे बस मौजूद थीं। उसके बाद जोड़ी गई टेबल माइग्रेशन स्क्रिप्ट से आईं, और वे स्क्रिप्ट रिपॉज़िटरी में हैं — 17 परिभाषाएँ वहीं से आती हैं। बाद में जोड़े गए कॉलम प्रॉम्प्ट पर टाइप किए गए एक लाइन के ALTER TABLE से जोड़े गए, क्योंकि जिस बदलाव में एक सेकंड लगता था, उसके लिए स्क्रिप्ट लिखने से ज़्यादा तेज़ उसे टाइप करना था।

इंडेक्स सबसे बुरा मामला हैं। इंडेक्स तब जोड़ा जाता है जब कुछ धीमा हो, ठीक उसी पल जब वह धीमा हो, और वह समस्या तुरंत ठीक कर देता है। पीछे कोई निशान नहीं छूटता, समीक्षा के लिए कुछ नहीं, ऐसा कुछ नहीं जो भूल जाने पर फ़ेल हो। यहाँ के बत्तीस सेकंडरी इंडेक्स में से ग्यारह ठीक इसी वजह से मौजूद हैं और कहीं दर्ज नहीं हैं।

जिस टेबल में खुद काउंटर रखे जाते हैं, उसमें 1,66,438 पंक्तियाँ हैं, और वह उन पंद्रह टेबलों में है, जिनकी रिपॉज़िटरी में कोई परिभाषा नहीं।

असल में क्या टूटता है

खास कुछ नहीं, जब तक एक खास पल न आए: जब डेटाबेस को डंप से रीस्टोर किया जाता है।

डंप अपने साथ संरचना ले जाता है, इसलिए सीधा रीस्टोर ठीक रहता है। खतरा हर उस रास्ते में है, जो किसी टेबल को रीस्टोर करने के बजाय दोबारा बनाता है — दूसरी मशीन पर जाना, चुनी हुई टेबल इम्पोर्ट करना, किसी स्क्रिप्ट से एक टेबल दोबारा बनाना। डेटा लौट आता है और इंडेक्स चुपचाप नहीं लौटते। कुछ फ़ेल नहीं होता। क्वेरी सही जवाब देती हैं। बस उन्हें ज़्यादा समय लगता है, और वजह दिखती नहीं, क्योंकि इंडेक्स क्या था, इसका अकेला रिकॉर्ड वह मशीन है जिसके पास अब वह नहीं है।

यही वह नाकामी है, जिसका नाम लेना ज़रूरी है: गायब इंडेक्स कोई गड़बड़ी नहीं देता, वह एक धीमा सही जवाब देता है। इसके लिए कोई टेस्ट नहीं है, क्योंकि टेस्ट पास हो जाते हैं।

तब तक हम इसके लिए क्या करते हैं

आज स्कीमा रिपॉज़िटरी में नहीं है, और स्थिति का सही बयान यही है। जो व्यवस्था है, वह पूरे समाधान से छोटी है, और वह उस मामले को कवर करती है, जिसकी असल में कीमत चुकानी पड़ती है:

कुछ भी नष्ट करने वाले काम से पहले एक डंप, वेब रूट से बाहर रखा हुआ। एक रीस्टोर, जो कम से कम एक बार सचमुच किया गया है, सिर्फ़ माना नहीं गया। और हर रीस्टोर के बाद जाँची जाने वाली एक छोटी सूची, उन इंडेक्स की, जिनके बारे में पता है कि वे सिर्फ़ चल रहे डेटाबेस में मौजूद हैं — क्योंकि मशीन से पूछा जा सकता है कि उसके पास कौन-से इंडेक्स हैं, और जवाब की तुलना पिछली बार के जवाब से की जा सकती है।

यह आम सबक डेटाबेस से आगे भी लागू होता है। अगर किसी सिस्टम का कोई हिस्सा सिर्फ़ चल रहे सिस्टम में मौजूद है, तो उसकी कोई दूसरी कॉपी नहीं है। किसी भी इन्फ्रास्ट्रक्चर के बारे में पूछने लायक सवाल यह नहीं कि उसका बैकअप है या नहीं, बल्कि यह कि मशीन न रहे, तो रिपॉज़िटरी से क्या दोबारा नहीं बनाया जा सकेगा। यहाँ जवाब है पंद्रह टेबल और ग्यारह इंडेक्स; इसे पता करने में एक दोपहर लगी, और अब यह कोई अनजानी चीज़ नहीं, बल्कि एक सूची है।

अपडेट: सितंबर 2026

यह पोस्ट आने के पाँच दिन बाद वर्किंग डायरेक्टरी को कमिट किया गया: 26 फ़ाइलें और 4,058 लाइनें, जिनमें 28 अगस्त से 1 सितंबर के बीच लिखी गई ग्यारह माइग्रेशन स्क्रिप्ट भी थीं, जो तब तक सिर्फ़ चल रही मशीन पर मौजूद थीं। यह आसान आधा हिस्सा था — ऐसा कोड, जो लिखा तो गया था, पर कभी दर्ज नहीं हुआ।

माप 1 सितंबर 2026 को उसी तरह दोहराया गया: लाइव डेटाबेस बनाम वह सब कुछ, जिसे git ट्रैक करता है।

टेबल	46	30 का रिपॉज़िटरी में CREATE TABLE है, 16 का कोई नहीं
सेकंडरी इंडेक्स	43	32 रिपॉज़िटरी के कोड से बने, 11 सिर्फ़ चल रहे डेटाबेस में
माइग्रेशन स्क्रिप्ट	109	वर्ज़न कंट्रोल में

जो संख्या मायने रखती है, वह नहीं हिली। 27 अगस्त को ग्यारह सेकंडरी इंडेक्स चल रहे डेटाबेस के अलावा कहीं मौजूद नहीं थे। 1 सितंबर को भी ग्यारह हैं। बीच में ग्यारह और इंडेक्स जोड़े गए, और हर एक माइग्रेशन स्क्रिप्ट के साथ आया: आदत बदल गई, कर्ज़ नहीं।

ये ग्यारह पाँच टेबलों पर हैं — काउंटर, भाषाएँ, रेफ़रर, बाहर रखने की सूची और इवेंट लॉग। पाँचों मौजूदा कोडबेस से पुरानी हैं, और ठीक इसीलिए उनके लिए कभी कुछ लिखा नहीं गया। अब फ़ाइल लिखने का मतलब होगा, चल रहे सर्वर से उस चीज़ को दोबारा गढ़ना, जो सालों पहले किसी प्रॉम्प्ट पर टाइप की गई थी।

इसलिए अगस्त वाली स्थिति कायम है। स्कीमा अब भी रिपॉज़िटरी में नहीं है, और जो रीस्टोर किसी टेबल को रीस्टोर करने के बजाय दोबारा बनाता है, वह अब भी बिना कुछ कहे ग्यारह इंडेक्स गँवा देगा। जो बदला है, वह छोटा है: तब से जो कुछ जोड़ा गया, उसने अपने पीछे एक फ़ाइल छोड़ी है।