Le query piccole funzionano, quelle grandi falliscono: quale dimensione del pacchetto?
I pacchetti del driver di SQL Server, i limiti dei messaggi di MySQL e l'MTU di un percorso IP sono unità diverse. Un guasto dipendente dalla dimensione non le rende intercambiabili.
Le query piccole tornano, quelle grandi si bloccano o cadono, e il primo istinto è che qualcosa non va nella dimensione del pacchetto. Quell'istinto di solito è giusto e quasi sempre punta al livello sbagliato. Tre impostazioni condividono la parola pacchetto e misurano tre cose non correlate: l'incapsulamento di trasporto di un driver di database, il limite di messaggi di un server di database e l'unità massima di trasmissione del percorso IP. Regolare una per correggere un sintomo causato da un'altra è il modo in cui un problema di cinque minuti diventa una settimana di regolazioni. L'ordine qui sotto è quello che mi è costato meno tempo.
Tre livelli, una parola condivisa
Ogni riga qui sotto è un'unità diversa con un proprietario diverso, e nessuna può essere dedotta dalle altre. Un messaggio di database può estendersi su molti segmenti TCP e molti pacchetti IP, quindi aumentarne la dimensione consentita non allarga il percorso, e ridurre un'impostazione del driver non è la stessa operazione che cambiare l'MTU di un'interfaccia. La parola compare in tre file di configurazione diversi, per questo cercarla restituisce tre risposte non correlate. Leggi prima il testo dell'errore, poi decidi quale file aprire.
| 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 |
Annota a quale livello appartiene l'operazione che fallisce prima di aprire un file di configurazione. Il testo dell'errore di solito lo dice, ed è proprio la parte che le persone saltano.
Identifica il provider prima di cambiarne l'impostazione
Per SQL Server, annota l'applicazione, il nome del driver o del provider, la versione e la configurazione effettiva della connessione. Uno script diagnostico e un'applicazione desktop possono raggiungere lo stesso server tramite provider diversi, quindi un'impostazione che aiuta uno non dimostra nulla sull'altro. I valori predefiniti dei provider differiscono, e un campo della stringa di connessione con un nome simile non è prova che ogni provider lo interpreti allo stesso modo.
Non sostituire un driver mantenuto con uno vecchio solo perché una vecchia soluzione usava la sua sintassi. La documentazione attuale sconsiglia nuovo sviluppo su quei componenti più vecchi, e ereditarne i limiti è un cattivo scambio per una sola impostazione.
Il rifiuto di un messaggio non è un blocco del percorso
In MySQL 8.4, la documentazione dei pacchetti di comunicazione descrive il rifiuto di un'istruzione, riga o evento di log binario troppo grande rispetto al limite applicabile, e possono contare sia il limite del client sia quello del server. È un rifiuto a livello di database, non l'affermazione che la rete debba trasportare un pacchetto IP gigantesco. Leggi l'errore reale e la forma del messaggio incriminato: un risultato grande fatto di molte righe piccole è un caso diverso da una sola riga enorme, e falliscono in modo diverso.
Le installazioni MariaDB hanno bisogno dei limiti e della diagnostica documentati della propria versione. Copiare i valori predefiniti di MySQL su MariaDB è indovinare con passaggi extra.
Che aspetto hanno davvero le prove del percorso
Un problema di dimensione del percorso ha la sua impronta: un guasto di trasporto riproducibile e dipendente dalla dimensione lungo una particolare rotta e famiglia di indirizzi, con l'overhead del tunnel in gioco e il feedback di discovery che si comporta come il percorso consente. Un timeout da solo non lo distingue da una query lenta, da un bug del driver o da un limite lato server, e trattare un timeout come prova di problemi MTU ti manda con sicurezza al livello sbagliato.
Se testi il percorso, mantieni fissi destinazione, account e carico di lavoro così che l'unica variabile sia la dimensione che stai sondando. Un test in cui sono cambiate tre cose non ti dice quale contava.
Cambia una variabile documentata, poi registrala
Mantieni costanti destinazione, account, provider e carico di lavoro, registra il valore originale, applica una modifica supportata e registra il risultato. Un'impostazione più piccola che fa passare un test è una prova utile su quello stack testato; non è un ottimo universale e non stabilisce cosa ha causato il guasto originale. Sono affermazioni diverse, e solo la prima è supportata da un singolo esperimento.
Risolvi il limite identificato al suo livello, poi annota di quale livello si trattava. La nota è ciò che impedisce alla persona successiva di regolare il driver perché il percorso era il problema.