ছোট কোয়েরি কাজ করে, বড়গুলো ব্যর্থ হয়: কোন প্যাকেট আকারটি দায়ী?

ছোট কোয়েরি ফিরে আসে, বড়গুলো আটকে যায় বা ঝরে পড়ে, আর প্রথম অনুমান হয় যে প্যাকেটের আকার নিয়ে কিছু ভুল আছে। সেই অনুমান সাধারণত ঠিক এবং প্রায় সবসময় ভুল স্তরে লক্ষ্য করে। তিনটি সেটিং প্যাকেট শব্দটি ভাগ করে এবং তিনটি অসংযুক্ত বিষয় মাপে: একটি ডেটাবেস ড্রাইভারের পরিবহন প্যাকেজিং, একটি ডেটাবেস সার্ভারের বার্তা সীমা এবং IP পথের সর্বোচ্চ ট্রান্সমিশন ইউনিট। একটিকে সামঞ্জস্য করে অন্যের সৃষ্ট উপসর্গ সারানোই পাঁচ মিনিটের সমস্যাকে এক সপ্তাহের টিউনিংয়ে পরিণত করার পথ। নিচের ক্রমটিই আমার সবচেয়ে কম সময় নিয়েছে।

তিন স্তর, এক সাধারণ শব্দ

নিচের প্রতিটি সারি ভিন্ন মালিকের ভিন্ন একক, এবং কোনোটির বিষয়ে অন্যগুলো থেকে যুক্তি দেওয়া যায় না। একটি ডেটাবেস বার্তা অনেক TCP সেগমেন্ট এবং অনেক IP প্যাকেট জুড়ে থাকতে পারে, তাই এর অনুমোদিত আকার বাড়ালে পথ বড় হয় না, আর ড্রাইভারের সেটিং কমানো ইন্টারফেস MTU বদলানোর মতো একই কাজ নয়। শব্দটি তিনটি ভিন্ন কনফিগারেশন ফাইলে দেখা যায়, তাই এটি খুঁজলে তিনটি অসংযুক্ত উত্তর আসে। আগে ত্রুটির লেখাটি পড়ুন, তারপর ঠিক করুন কোন ফাইল খুলবেন।

কনফিগারেশন ফাইল খোলার আগে লিখে রাখুন ব্যর্থ কাজটি কোন স্তরের। ত্রুটির লেখা সাধারণত তা বলে, আর ত্রুটির লেখাটাই সেই অংশ যা মানুষ এড়িয়ে যায়।

সেটিং বদলানোর আগে প্রোভাইডার শনাক্ত করুন

SQL Server-এর জন্য অ্যাপ্লিকেশন, ড্রাইভার বা প্রোভাইডারের নাম, সংস্করণ এবং কার্যকর সংযোগ কনফিগারেশন লিখে রাখুন। একটি ডায়াগনস্টিক স্ক্রিপ্ট এবং একটি ডেস্কটপ অ্যাপ্লিকেশন ভিন্ন প্রোভাইডারের মাধ্যমে একই সার্ভারে পৌঁছাতে পারে, তাই একটিকে সাহায্য করা সেটিং অন্যটি সম্পর্কে কিছু প্রমাণ করে না। প্রোভাইডারগুলোর ডিফল্ট ভিন্ন, এবং একই নামের সংযোগ-স্ট্রিং ফিল্ডের উপস্থিতি প্রমাণ নয় যে প্রতিটি প্রোভাইডার এটিকে একইভাবে ব্যাখ্যা করে।

শুধু পুরোনো একটি সমাধান এর সিনট্যাক্স ব্যবহার করেছে বলে রক্ষণাবেক্ষণকৃত ড্রাইভারকে পুরোনো দিয়ে বদলাবেন না। বর্তমান ডকুমেন্টেশন ওই পুরোনো উপাদানগুলোর বিরুদ্ধে নতুন উন্নয়ন নিরুৎসাহিত করে, এবং তাদের সীমাবদ্ধতা উত্তরাধিকারে নেওয়া একটি সেটিংয়ের জন্য খারাপ বিনিময়।

বার্তা প্রত্যাখ্যান পথের স্থবিরতা নয়

MySQL 8.4-এ যোগাযোগ-প্যাকেট ডকুমেন্টেশন বর্ণনা করে যে অতিরিক্ত বড় একটি স্টেটমেন্ট, সারি বা বাইনারি-লগ ইভেন্ট প্রযোজ্য সীমার বিপরীতে প্রত্যাখ্যাত হয়, এবং ক্লায়েন্ট ও সার্ভার উভয় সীমাই গুরুত্বপূর্ণ হতে পারে। এটি ডেটাবেস স্তরে প্রত্যাখ্যান, নয়তো এই বিবৃতি নয় যে নেটওয়ার্ককে বিশাল IP প্যাকেট বহন করতে হবে। প্রকৃত ত্রুটি এবং সমস্যাযুক্ত বার্তার আকৃতি পড়ুন: অনেক ছোট সারির বড় ফলাফল একটি বিশাল সারি থেকে ভিন্ন ঘটনা, এবং তারা ভিন্নভাবে ব্যর্থ হয়।

MariaDB ইনস্টলেশনের নিজস্ব সংস্করণের নথিভুক্ত সীমা ও ডায়াগনস্টিক দরকার। MySQL-এর ডিফল্ট MariaDB-তে কপি করা অতিরিক্ত ধাপসহ অনুমান করা।

পথের প্রমাণ আসলে কেমন দেখায়

পথ-আকারের সমস্যার নিজস্ব ছাপ আছে: নির্দিষ্ট একটি রুট ও ঠিকানা-পরিবারে পুনরুৎপাদনযোগ্য আকার-নির্ভর পরিবহন ব্যর্থতা, যেখানে টানেলের অতিরিক্ত ভার কাজ করে এবং আবিষ্কার-প্রতিক্রিয়া পথ যেভাবে অনুমোদন করে সেভাবে আচরণ করে। একা একটি টাইমআউট এটিকে ধীর কোয়েরি, ড্রাইভার বাগ বা সার্ভার-পক্ষের সীমা থেকে আলাদা করে না, এবং টাইমআউটকে MTU সমস্যার প্রমাণ ধরে নেওয়া আপনাকে আত্মবিশ্বাসের সঙ্গে ভুল স্তরে পাঠায়।

আপনি যদি সত্যিই পথ পরীক্ষা করেন, গন্তব্য, অ্যাকাউন্ট ও কাজের ভার স্থির রাখুন যাতে একমাত্র পরিবর্তনশীল হয় আপনি যে আকার যাচাই করছেন। যে পরীক্ষায় তিনটি জিনিস বদলেছে তা কোনটি গুরুত্বপূর্ণ ছিল সে বিষয়ে কিছু বলে না।

একটি নথিভুক্ত ভেরিয়েবল বদলান, তারপর তা লিখে রাখুন

গন্তব্য, অ্যাকাউন্ট, প্রোভাইডার ও কাজের ভার স্থির রাখুন, মূল মান লিখে রাখুন, একটি সমর্থিত পরিবর্তন প্রয়োগ করুন এবং ফলাফল লিখে রাখুন। ছোট সেটিং যা একটি পরীক্ষা সফল করে তা ওই পরীক্ষিত স্ট্যাক সম্পর্কে উপকারী প্রমাণ; এটি সর্বজনীন সর্বোত্তম নয় এবং মূল ব্যর্থতার কারণও প্রতিষ্ঠা করে না। এগুলো ভিন্ন দাবি, এবং কেবল প্রথমটিই একটি পরীক্ষা দ্বারা সমর্থিত।

চিহ্নিত সীমাটি তার নিজের স্তরেই সমাধান করুন, তারপর নোট করুন কোন স্তর ছিল। সেই নোটই পরের ব্যক্তিকে ড্রাইভার টিউন করা থেকে থামায় কারণ সমস্যা ছিল পথে।