Små frågor fungerar, stora misslyckas: vilken paketstorlek är det?
SQL Server-drivrutinspaket, MySQL-meddelandegränser och MTU:n för en IP-väg är olika enheter. Ett storleksberoende fel gör dem inte utbytbara.
Små frågor kommer tillbaka, stora hänger eller faller, och den första tanken är att något är fel med paketstorleken. Den tanken stämmer oftast och riktas nästan alltid mot fel lager. Tre inställningar delar ordet paket och mäter tre oberoende saker: en databasdrivrutins transportförpackning, en databasservers meddelandegräns och IP-vägens maximala överföringsenhet. Att justera en för att åtgärda ett symptom som en annan orsakat är hur ett femminutersproblem blir en vecka av trimning. Ordningen nedan är den som kostat mig minst tid.
Tre lager, ett gemensamt ord
Varje rad nedan är en annan enhet med en annan ägare, och ingen av dem kan resoneras fram ur de andra. Ett databasmeddelande kan sträcka sig över många TCP-segment och många IP-paket, så att öka den tillåtna storleken breddar inte vägen, och att sänka en drivrutinsinställning är inte samma åtgärd som att ändra en gränssnitts-MTU. Ordet förekommer i tre olika konfigurationsfiler, därför ger en sökning efter det tre oberoende svar. Läs feltexten först och bestäm dig sedan för vilken fil du öppnar.
| 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 |
Skriv ner vilket lager den misslyckade åtgärden hör till innan du öppnar en konfigurationsfil. Feltexten säger det oftast, och feltexten är just den del folk hoppar över.
Identifiera leverantören innan du ändrar dess inställning
För SQL Server, registrera programmet, namnet på drivrutinen eller leverantören, versionen och den effektiva anslutningskonfigurationen. Ett diagnostikskript och ett skrivbordsprogram kan nå samma server via olika leverantörer, så en inställning som hjälper den ena bevisar ingenting om den andra. Leverantörernas standardvärden skiljer sig, och ett liknande namngivet fält i anslutningssträngen är inte bevis för att varje leverantör tolkar det likadant.
Byt inte ut en underhållen drivrutin mot en äldre bara för att en gammal lösning använde dess syntax. Nuvarande dokumentation avråder från ny utveckling mot de äldre komponenterna, och att ärva deras begränsningar är en dålig affär för en enda inställning.
Avvisning av ett meddelande är inte ett vägstopp
I MySQL 8.4 beskriver dokumentationen för kommunikationspaketet att en för stor sats, rad eller binärlogghändelse avvisas mot gällande gräns, och både klient- och servergränsen kan spela roll. Det är en avvisning på databaslagret, inte ett påstående att nätverket måste bära ett gigantiskt IP-paket. Läs det faktiska felet och formen på det problematiska meddelandet: ett stort resultat av många små rader är ett annat fall än en enda enorm rad, och de misslyckas olika.
MariaDB-installationer behöver sina egna versioners dokumenterade gränser och diagnostik. Att kopiera MySQL-standardvärden till MariaDB är gissning med extra steg.
Hur vägbevis faktiskt ser ut
Ett vägstorleksproblem har sitt eget fingeravtryck: ett reproducerbart storleksberoende transportfel längs en viss rutt och adressfamilj, med tunnelns overhead i spel och upptäcktsåterkopplingen som beter sig som vägen tillåter. En timeout ensam skiljer det inte från en långsam fråga, en drivrutinsbugg eller en servergräns, och att behandla en timeout som bevis för MTU-problem skickar dig med självförtroende till fel lager.
Om du testar vägen, håll destination, konto och arbetsbelastning fasta så att den enda variabeln är storleken du undersöker. Ett test där tre saker ändrades säger ingenting om vilken som spelade roll.
Ändra en dokumenterad variabel och registrera den sedan
Håll destination, konto, leverantör och arbetsbelastning konstanta, registrera det ursprungliga värdet, tillämpa en enda stödd ändring och registrera resultatet. En mindre inställning som får ett test att lyckas är ett användbart bevis om den testade stacken; den är inte ett universellt optimum och fastställer inte vad som orsakade det ursprungliga felet. Det är olika påståenden, och bara det första stöds av ett enda experiment.
Lös den identifierade gränsen på sitt eget lager och notera sedan vilket lager det var. Anteckningen är det som hindrar nästa person från att trimma drivrutinen eftersom vägen var problemet.