پرسوجوهای کوچک کار میکنند، بزرگها شکست میخورند: کدام اندازه بسته است؟
بستههای درایور SQL Server، محدودیت پیام MySQL و MTU یک مسیر IP واحدهای متفاوتی هستند. شکست وابسته به اندازه آنها را قابل تعویض نمیکند.
پرسوجوهای کوچک برمیگردند، بزرگها گیر میکنند یا قطع میشوند، و نخستین حدس این است که چیزی درباره اندازه بسته اشتباه است. این حدس معمولاً درست است و تقریباً همیشه لایه اشتباه را هدف میگیرد. سه تنظیم واژه بسته را شریکاند و سه چیز بیارتباط را میسنجند: بستهبندی انتقالی یک درایور پایگاه داده، محدودیت پیام یک سرور پایگاه داده، و بیشترین واحد انتقال مسیر 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 شما را با اطمینان به لایه اشتباه میفرستد.
اگر مسیر را آزمودید، مقصد، حساب و بار کاری را ثابت نگه دارید تا تنها متغیر اندازهای باشد که بررسی میکنید. آزمونی که در آن سه چیز تغییر کرده باشد چیزی درباره اینکه کدام مهم بود نمیگوید.
یک متغیر مستند را تغییر دهید و سپس آن را ثبت کنید
مقصد، حساب، ارائهدهنده و بار کاری را ثابت نگه دارید، مقدار اصلی را ثبت کنید، یک تغییر پشتیبانیشده را اعمال کنید و نتیجه را ثبت کنید. تنظیم کوچکتری که یک آزمون را موفق میکند شاهد سودمندی درباره همان پشته آزمودهشده است؛ نه بهینه جهانی است و نه مشخص میکند علت شکست اصلی چه بود. اینها ادعاهای متفاوتی هستند و تنها اولی با یک آزمایش واحد پشتیبانی میشود.
محدودیت شناساییشده را در لایه خودش حل کنید، سپس بنویسید که کدام لایه بود. همان یادداشت مانع میشود که نفر بعدی چون مسیر مشکل بود درایور را تنظیم کند.