Interogările mici funcționează, cele mari eșuează: care dimensiune a pachetului?
Pachetele driverului SQL Server, limitele de mesaje MySQL și MTU-ul unei căi IP sunt unități diferite. O defecțiune dependentă de dimensiune nu le face interschimbabile.
Interogările mici revin, cele mari se blochează sau cad, iar primul instinct este că ceva nu este în regulă cu dimensiunea pachetului. Acel instinct este de obicei corect și aproape întotdeauna îndreptat spre stratul greșit. Trei setări împart cuvântul pachet și măsoară trei lucruri fără legătură: ambalarea de transport a unui driver de bază de date, limita de mesaje a unui server de bază de date și unitatea maximă de transmisie a căii IP. Reglarea uneia pentru a remedia un simptom cauzat de alta este felul în care o problemă de cinci minute devine o săptămână de reglaje. Ordinea de mai jos este cea care m-a costat cel mai puțin timp.
Trei straturi, un cuvânt comun
Fiecare rând de mai jos este o unitate diferită cu un proprietar diferit, și despre niciuna nu se poate raționa pornind de la celelalte. Un mesaj de bază de date poate acoperi multe segmente TCP și multe pachete IP, deci mărirea dimensiunii permise nu lărgește calea, iar reducerea unei setări a driverului nu este aceeași operație ca schimbarea MTU-ului unei interfețe. Cuvântul apare în trei fișiere de configurare diferite, de aceea căutarea lui returnează trei răspunsuri fără legătură. Citiți mai întâi textul erorii, apoi decideți ce fișier deschideți.
| 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 |
Notați cărui strat îi aparține operația care eșuează înainte de a deschide un fișier de configurare. Textul erorii spune de obicei acest lucru, și exact acea parte este sărită de oameni.
Identificați furnizorul înainte de a-i schimba setarea
Pentru SQL Server, notați aplicația, numele driverului sau al furnizorului, versiunea și configurația efectivă a conexiunii. Un script de diagnostic și o aplicație desktop pot ajunge la același server prin furnizori diferiți, așa că o setare care ajută unul nu dovedește nimic despre celălalt. Valorile implicite ale furnizorilor diferă, iar un câmp din șirul de conexiune cu nume similar nu este dovada că fiecare furnizor îl interpretează la fel.
Nu înlocuiți un driver întreținut cu unul vechi doar pentru că o soluție veche folosea sintaxa lui. Documentația actuală descurajează dezvoltarea nouă pe acele componente mai vechi, iar moștenirea limitărilor lor este un schimb prost pentru o singură setare.
Respingerea unui mesaj nu este o oprire a căii
În MySQL 8.4, documentația pachetului de comunicație descrie respingerea unei instrucțiuni, linii sau eveniment de jurnal binar prea mare față de limita aplicabilă, iar atât limita clientului, cât și cea a serverului pot conta. Aceasta este o respingere la nivelul bazei de date, nu afirmația că rețeaua trebuie să transporte un pachet IP gigantic. Citiți eroarea reală și forma mesajului problematic: un rezultat mare format din multe linii mici este un caz diferit de o singură linie uriașă, și eșuează în moduri diferite.
Instalările MariaDB au nevoie de limitele și diagnosticele documentate ale propriei versiuni. Copierea valorilor implicite MySQL pe MariaDB este ghicit cu pași suplimentari.
Cum arată de fapt dovada căii
O problemă de dimensiune a căii are propria amprentă: o defecțiune de transport reproductibilă și dependentă de dimensiune pe o anumită rută și familie de adrese, cu suprasarcina tunelului în joc și feedbackul de descoperire comportându-se cum permite calea. Un singur timeout nu o distinge de o interogare lentă, de un bug al driverului sau de o limită pe partea serverului, iar tratarea unui timeout ca dovadă a problemelor MTU te trimite cu încredere la stratul greșit.
Dacă testați calea, păstrați fixe destinația, contul și volumul de lucru, astfel încât singura variabilă să fie dimensiunea pe care o sondai. Un test în care s-au schimbat trei lucruri nu vă spune care dintre ele a contat.
Schimbați o variabilă documentată, apoi notați-o
Păstrați constante destinația, contul, furnizorul și volumul de lucru, notați valoarea originală, aplicați o singură schimbare acceptată și notați rezultatul. O setare mai mică ce face un test să reușească este o dovadă utilă despre acel stack testat; nu este un optim universal și nu stabilește ce a cauzat defecțiunea originală. Sunt afirmații diferite, și doar prima este susținută de un singur experiment.
Rezolvați limita identificată la propriul strat, apoi notați care strat a fost. Nota este ceea ce împiedică următoarea persoană să regleze driverul pentru că problema era calea.