A kis lekérdezések működnek, a nagyok elbuknak: melyik csomagméret ez?
Az SQL Server illesztőprogramjának csomagjai, a MySQL üzenethatárai és egy IP-útvonal MTU-ja különböző egységek. A mérettől függő hiba nem teszi őket felcserélhetővé.
A kis lekérdezések visszatérnek, a nagyok lefagynak vagy megszakadnak, és az első ösztön az, hogy valami baj van a csomagmérettel. Ez az ösztön általában helyes, és szinte mindig a rossz réteget célozza. Három beállítás osztozik a csomag szón, és három, egymással nem összefüggő dolgot mér: egy adatbázis-illesztőprogram szállítási csomagolását, egy adatbázis-kiszolgáló üzenethatárát és az IP-útvonal maximális átviteli egységét. Az egyiket a másik okozta tünet javítására állítani az az út, amelyen egy ötperces probléma egyhetes hangolássá válik. Az alábbi sorrend az, amely a legkevesebb időmbe került.
Három réteg, egy közös szó
Az alábbi minden sor más egység, más tulajdonossal, és egyik sem vezethető le a többiből. Egy adatbázis-üzenet sok TCP-szegmenst és sok IP-csomagot foghat át, ezért az engedélyezett méret növelése nem szélesíti az útvonalat, és az illesztőprogram-beállítás csökkentése nem ugyanaz a művelet, mint egy interfész MTU-jának módosítása. A szó három különböző konfigurációs fájlban jelenik meg, ezért a rá való keresés három, egymással nem összefüggő választ ad. Először a hibaüzenetet olvasd el, aztán döntsd el, melyik fájlt nyisd meg.
| 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 |
Jegyezd fel, melyik réteghez tartozik a sikertelen művelet, mielőtt megnyitsz egy konfigurációs fájlt. A hibaüzenet általában megmondja, és éppen ezt a részt szokták kihagyni.
A beállítás módosítása előtt azonosítsd a szolgáltatót
SQL Server esetén jegyezd fel az alkalmazást, az illesztőprogram vagy szolgáltató nevét, a verziót és a tényleges kapcsolatkonfigurációt. Egy diagnosztikai szkript és egy asztali alkalmazás különböző szolgáltatókon keresztül érheti el ugyanazt a kiszolgálót, ezért az egyiknek segítő beállítás semmit sem bizonyít a másikról. A szolgáltatók alapértékei eltérnek, és egy hasonló nevű kapcsolati karakterlánc-mező nem bizonyítja, hogy minden szolgáltató ugyanúgy értelmezi.
Ne cserélj karbantartott illesztőprogramot régiire csak azért, mert egy régi kerülő megoldás annak szintaxisát használta. A jelenlegi dokumentáció nem támogatja az új fejlesztést ezeken a régebbi összetevőkön, és a korlátaik öröklése rossz üzlet egyetlen beállításért.
Az üzenet elutasítása nem útvonal-elakadás
A MySQL 8.4-ben a kommunikációs csomag dokumentációja leírja, hogy a túl nagy utasítás, sor vagy bináris naplóesemény elutasításra kerül az alkalmazandó korlát ellenében, és az ügyfél- és a kiszolgálóoldali korlát is számíthat. Ez elutasítás az adatbázis rétegén, nem annak kijelentése, hogy a hálózatnak gigantikus IP-csomagot kell szállítania. Olvasd el a tényleges hibát és a problémás üzenet formáját: a sok kis sorból álló nagy eredmény más eset, mint egyetlen hatalmas sor, és másképp vallanak kudarcot.
A MariaDB-telepítéseknek a saját verziójuk dokumentált korlátaira és diagnosztikájára van szükségük. A MySQL alapértékeit MariaDB-re másolni tippelés extra lépésekkel.
Hogyan néz ki valójában az útvonal bizonyítéka
Az útvonal méretének problémájának saját ujjlenyomata van: reprodukálható, mérettől függő szállítási hiba egy adott útvonalon és címcsaládon, az alagút többletterhelésével a játékban és a felderítési visszacsatolással úgy viselkedve, ahogy az útvonal engedi. Egy időtúllépés önmagában nem különbözteti meg egy lassú lekérdezéstől, illesztőprogram-hibától vagy kiszolgálóoldali korláttól, és egy időtúllépés MTU-problémák bizonyítékaként való kezelése magabiztosan a rossz rétegre küld.
Ha mégis teszteled az útvonalat, tartsd fixen a célt, a fiókot és a munkaterhelést, hogy az egyetlen változó a méret legyen, amelyet vizsgálsz. Egy teszt, amelyben három dolog változott, semmit sem mond arról, melyik számított.
Módosíts egy dokumentált változót, majd jegyezd fel
Tartsd állandóan a célt, a fiókot, a szolgáltatót és a munkaterhelést, jegyezd fel az eredeti értéket, hajts végre egy támogatott változtatást, és jegyezd fel az eredményt. Egy kisebb beállítás, amelytől egy teszt sikerül, hasznos bizonyíték arról a tesztelt veremről; nem univerzális optimum, és nem állapítja meg, mi okozta az eredeti hibát. Ezek különböző állítások, és csak az elsőt támasztja alá egyetlen kísérlet.
Oldd meg az azonosított korlátot a saját rétegén, majd jegyezd fel, melyik réteg volt. A feljegyzés az, ami megakadályozza a következő embert abban, hogy az illesztőprogramot hangolja, mert az útvonal volt a probléma.