Малките заявки работят, големите се провалят: кой размер на пакета е виновен?
Пакетите на драйвера за 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 ви изпраща уверено на грешния слой.
Ако все пак тествате пътя, дръжте дестинацията, акаунта и натоварването фиксирани, така че единствената променлива да е размерът, който проверявате. Тест, в който са се променили три неща, не ви казва кое е имало значение.
Променете една документирана променлива, после я запишете
Дръжте дестинацията, акаунта, доставчика и натоварването постоянни, запишете първоначалната стойност, приложете една поддържана промяна и запишете резултата. По-малка настройка, която кара един тест да успее, е полезно доказателство за този тестван стек; тя не е универсален оптимум и не установява какво е причинило първоначалния отказ. Това са различни твърдения и само първото се подкрепя от един експеримент.
Решете идентифицирания лимит на собствения му слой, после отбележете кой слой е бил. Бележката е това, което спира следващия човек да настройва драйвера, защото проблемът е бил в пътя.