साना क्वेरीहरू काम गर्छन्, ठूला असफल हुन्छन्: कुन प्याकेट आकार?
SQL Server ड्राइभरका प्याकेट, MySQL का सन्देश सीमा र IP मार्गको MTU फरक एकाइ हुन्। आकारमा निर्भर असफलताले तिनलाई परस्पर विनिमययोग्य बनाउँदैन।
साना क्वेरीहरू फर्कन्छन्, ठूला झुन्डिन्छन् वा खस्छन्, र पहिलो अनुमान प्याकेट आकारमा केही गडबड छ भन्ने हुन्छ। त्यो अनुमान प्रायः सही हुन्छ र लगभग सधैं गलत तहमा लक्ष्य राख्छ। तीनवटा सेटिङले प्याकेट शब्द साझा गर्छन् र तीन असम्बन्धित कुरा नाप्छन्: डेटाबेस ड्राइभरको यातायात प्याकेजिङ, डेटाबेस सर्भरको सन्देश सीमा र IP मार्गको अधिकतम प्रसारण एकाइ। एउटा समायोजन गरेर अर्कोले ल्याएको लक्षण सुधार्नु पाँच मिनेटको समस्यालाई एक हप्ताको ट्युनिङ बनाउने बाटो हो। तलको क्रम त्यही हो जसमा मलाई सबैभन्दा कम समय लाग्यो।
तीन तह, एउटै साझा शब्द
तलको हरेक पङ्क्ति फरक मालिकको फरक एकाइ हो, र तीमध्ये कुनैको बारेमा अरूबाट तर्क गर्न सकिँदैन। डेटाबेस सन्देश धेरै TCP खण्ड र धेरै IP प्याकेटसम्म फैलिन सक्छ, त्यसैले यसको अनुमति आकार बढाउँदा मार्ग फराकिलो हुँदैन, र ड्राइभर सेटिङ घटाउनु इन्टरफेसको MTU बदल्नु जस्तै उही कार्य होइन। शब्द तीन फरक कन्फिगरेसन फाइलमा आउँछ, त्यसैले यसलाई खोज्दा तीन असम्बन्धित उत्तर आउँछन्। पहिले त्रुटिको पाठ पढ्नुहोस्, त्यसपछि कुन फाइल खोल्ने निर्णय गर्नुहोस्।
| Setting or observation | Unit it describes |
|---|---|
| SQL Server client network packet setting | The provider's transport packaging for that connection |
| MySQL communication packet limit | A database message, such as one statement, row or replication event |
| IP path MTU | The largest IP packet the path carries without fragmentation handling |
कन्फिगरेसन फाइल खोल्नु अघि असफल कार्य कुन तहको हो लेख्नुहोस्। त्रुटिको पाठले प्रायः त्यही भन्छ, र मानिसहरूले छोड्ने भाग त्यही पाठ हो।
यसको सेटिङ बदल्नु अघि प्रदायक पहिचान गर्नुहोस्
SQL Server का लागि अनुप्रयोग, ड्राइभर वा प्रदायकको नाम, संस्करण र प्रभावकारी जडान कन्फिगरेसन लेख्नुहोस्। डायग्नोस्टिक स्क्रिप्ट र डेस्कटप अनुप्रयोग फरक प्रदायकमार्फत एउटै सर्भरमा पुग्न सक्छन्, त्यसैले एउटालाई मद्दत गर्ने सेटिङले अर्कोको बारेमा केही साबित गर्दैन। प्रदायकहरूको पूर्वनिर्धारित मान फरक हुन्छ, र जडान स्ट्रिङको समान नामको फिल्ड हरेक प्रदायकले यसलाई एउटै तरिकाले व्याख्या गर्छ भन्ने प्रमाण होइन।
पुरानो उपायले यसको सिन्ट्याक्स प्रयोग गरेको मात्र कारणले हेरचाह गरिएको ड्राइभरलाई पुरानोसँग नबदल्नुहोस्। हालको दस्तावेजीकरणले ती पुराना घटकमा नयाँ विकासलाई प्रोत्साहन दिँदैन, र तिनका सीमा उत्तराधिकारमा लिनु एउटा सेटिङका लागि खराब सौदा हो।
सन्देश अस्वीकार हुनु मार्गको रोकावट होइन
MySQL 8.4 मा, सञ्चार-प्याकेट दस्तावेजले लागू सीमाविरुद्ध धेरै ठूलो स्टेटमेन्ट, पङ्क्ति वा बाइनरी-लग घटना अस्वीकार गरिन्छ भनी वर्णन गर्छ, र क्लाइन्ट तथा सर्भर दुवैको सीमा महत्त्वपूर्ण हुन सक्छ। त्यो डेटाबेस तहमा अस्वीकार हो, नेटवर्कले विशाल IP प्याकेट बोक्नैपर्छ भन्ने कथन होइन। वास्तविक त्रुटि र समस्याग्रस्त सन्देशको आकार पढ्नुहोस्: धेरै साना पङ्क्तिबाट बनेको ठूलो नतिजा एउटा विशाल पङ्क्तिभन्दा फरक अवस्था हो, र ती फरक तरिकाले असफल हुन्छन्।
MariaDB स्थापनालाई आफ्नै संस्करणका दस्तावेजी सीमा र निदान चाहिन्छ। MySQL का पूर्वनिर्धारित मान MariaDB मा प्रतिलिपि गर्नु थप कदमसहित अनुमान गर्नु हो।
मार्गको प्रमाण वास्तवमा कस्तो देखिन्छ
मार्ग-आकारको समस्याको आफ्नै औंलाको छाप हुन्छ: कुनै विशेष मार्ग र ठेगाना-परिवारमा पुनरुत्पादनयोग्य आकार-निर्भर यातायात असफलता, जसमा टनेलको अतिरिक्त भार संलग्न हुन्छ र खोज-प्रतिक्रिया मार्गले अनुमति दिएअनुसार व्यवहार गर्छ। एउटै टाइमआउटले यसलाई ढिलो क्वेरी, ड्राइभर बग वा सर्भर-पक्षको सीमाबाट छुट्याउँदैन, र टाइमआउटलाई MTU समस्याको प्रमाण मान्नु तपाईंलाई आत्मविश्वासका साथ गलत तहमा पठाउँछ।
यदि तपाईंले मार्ग परीक्षण गर्नुभयो भने, गन्तव्य, खाता र कार्यभार स्थिर राख्नुहोस् ताकि एकमात्र चल तपाईंले जाँचिरहेको आकार होस्। जुन परीक्षणमा तीन कुरा बदलिए, त्यसले कुन महत्त्वपूर्ण थियो भनेर केही बताउँदैन।
एउटा दस्तावेजी चल बदल्नुहोस्, त्यसपछि त्यो लेख्नुहोस्
गन्तव्य, खाता, प्रदायक र कार्यभार स्थिर राख्नुहोस्, मूल मान लेख्नुहोस्, एउटा समर्थित परिवर्तन लागू गर्नुहोस् र नतिजा लेख्नुहोस्। एउटा परीक्षण सफल बनाउने सानो सेटिङ त्यो परीक्षण गरिएको स्ट्याकबारे उपयोगी प्रमाण हो; यो सार्वभौमिक उत्तम होइन र मूल असफलताको कारण के थियो भनी स्थापित गर्दैन। यी फरक दाबी हुन्, र पहिलोलाई मात्र एउटा प्रयोगले समर्थन गर्छ।
पहिचान गरिएको सीमालाई यसको आफ्नै तहमा समाधान गर्नुहोस्, त्यसपछि कुन तह थियो लेख्नुहोस्। त्यही टिप्पणीले अर्को व्यक्तिलाई ड्राइभर ट्युन गर्नबाट रोक्छ किनकि समस्या मार्गमा थियो।