Kleine Abfragen funktionieren, große scheitern: Welche Paketgröße ist es?
SQL-Server-Treiberpakete, MySQL-Nachrichtenlimits und die MTU eines IP-Pfads sind verschiedene Einheiten. Ein größenabhängiger Fehler macht sie nicht austauschbar.
Kleine Abfragen liefern zurück, große hängen oder brechen ab, und der erste Instinkt sagt, dass etwas mit der Paketgröße nicht stimmt. Dieser Instinkt ist meist richtig und fast immer auf die falsche Schicht gerichtet. Drei Einstellungen teilen sich das Wort Paket und messen drei unverbundene Dinge: die Transportverpackung eines Datenbanktreibers, das Nachrichtenlimit eines Datenbankservers und die maximale Übertragungseinheit des IP-Pfads. Eine davon zu justieren, um ein Symptom einer anderen zu beheben, ist der Weg, auf dem aus einem Fünf-Minuten-Problem eine Woche Tuning wird. Die Reihenfolge unten hat mich am wenigsten Zeit gekostet.
Drei Schichten, ein gemeinsames Wort
Jede Zeile unten ist eine andere Einheit mit einem anderen Eigentümer, und über keine davon lässt sich aus den anderen schließen. Eine Datenbanknachricht kann viele TCP-Segmente und viele IP-Pakete umfassen, daher vergrößert eine höhere erlaubte Größe den Pfad nicht, und eine Treibereinstellung zu senken ist nicht derselbe Vorgang wie eine Interface-MTU zu ändern. Das Wort steht in drei verschiedenen Konfigurationsdateien, weshalb eine Suche danach drei unverbundene Antworten liefert. Lies zuerst den Fehlertext und entscheide dann, welche Datei du öffnest.
| 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 |
Notiere, zu welcher Schicht der fehlschlagende Vorgang gehört, bevor du eine Konfigurationsdatei öffnest. Der Fehlertext sagt es meist, und genau diesen Teil überspringen die Leute.
Bestimme den Anbieter, bevor du seine Einstellung änderst
Für SQL Server notiere die Anwendung, den Treiber- oder Anbieternamen, die Version und die wirksame Verbindungskonfiguration. Ein Diagnoseskript und eine Desktop-Anwendung können denselben Server über verschiedene Anbieter erreichen, daher beweist eine Einstellung, die einem hilft, nichts über den anderen. Anbieterstandardwerte unterscheiden sich, und ein ähnlich benanntes Feld in der Verbindungszeichenfolge ist kein Beweis, dass jeder Anbieter es gleich interpretiert.
Ersetze keinen gepflegten Treiber durch einen alten, nur weil ein alter Workaround dessen Syntax nutzte. Die aktuelle Dokumentation rät von neuer Entwicklung gegen diese älteren Komponenten ab, und ihre Einschränkungen zu erben ist ein schlechter Tausch für eine Einstellung.
Nachrichtenabweisung ist kein Pfadstillstand
In MySQL 8.4 beschreibt die Dokumentation zu Kommunikationspaketen, dass eine zu große Anweisung, Zeile oder ein Binärlog-Ereignis gegen das geltende Limit abgewiesen wird, und sowohl Client- als auch Serverlimit können eine Rolle spielen. Das ist eine Abweisung auf der Datenbankschicht, keine Aussage, dass das Netzwerk ein gigantisches IP-Paket tragen muss. Lies den tatsächlichen Fehler und die Form der betroffenen Nachricht: ein großes Ergebnis aus vielen kleinen Zeilen ist ein anderer Fall als eine riesige Zeile, und sie scheitern unterschiedlich.
MariaDB-Installationen brauchen die dokumentierten Limits und die Diagnostik ihrer eigenen Version. MySQL-Standardwerte auf MariaDB zu kopieren ist Raten mit zusätzlichen Schritten.
Wie Pfadnachweise tatsächlich aussehen
Ein Pfadgrößenproblem hat seinen eigenen Fingerabdruck: ein reproduzierbarer größenabhängiger Transportfehler auf einer bestimmten Route und Adressfamilie, mit dem Overhead des Tunnels im Spiel und Discovery-Feedback, das sich verhält, wie es der Pfad zulässt. Ein Timeout allein unterscheidet es nicht von einer langsamen Abfrage, einem Treiberfehler oder einem serverseitigen Limit, und einen Timeout als Beweis für MTU-Probleme zu behandeln schickt dich mit Zuversicht auf die falsche Schicht.
Wenn du den Pfad testest, halte Ziel, Konto und Arbeitslast fest, damit die einzige Variable die Größe ist, die du prüfst. Ein Test, bei dem sich drei Dinge geändert haben, sagt dir nichts darüber, welches zählte.
Ändere eine dokumentierte Variable und protokolliere sie dann
Halte Ziel, Konto, Anbieter und Arbeitslast konstant, protokolliere den ursprünglichen Wert, wende eine unterstützte Änderung an und protokolliere das Ergebnis. Eine kleinere Einstellung, die einen Test bestehen lässt, ist ein nützlicher Beleg für diesen getesteten Stack; sie ist kein universelles Optimum und belegt nicht, was den ursprünglichen Fehler verursacht hat. Das sind verschiedene Aussagen, und nur die erste wird durch ein einzelnes Experiment gestützt.
Löse das identifizierte Limit auf seiner eigenen Schicht und notiere dann, welche Schicht es war. Die Notiz ist es, die die nächste Person davon abhält, den Treiber zu tunen, weil der Pfad das Problem war.