Nicht "Packet Too Large" Fehler mit riesigen Paketen

Question

Meine Situation ist ziemlich geradlinig.

Ich habe einen Server konfiguriert mit max_allowed_packet auf 16M festgelegt. Es läuft Percona Server 5.1.52.

Ich schrieb ein einfaches Skript in Perl, um riesige Masseneinsätze zu machen. Ich weiß ungefähr die Größe der Pakete, indem ich weiß, wie groß der Datenstring ist, den ich über DBI sende.

Egal, welche Größe die Masseneinfügung MySQL scheint das Paket anzunehmen und die Einfügung zu tun, aber ich erwarte, dass es mir einen Packet Too Large Fehler für alles über 16M geben.

Hier ist, wo es wirklich seltsam bekommt ...

Wenn ich die max_allowed_packet zu 16.777.215 (ein Byte weniger als 16M) oder etwas niedriger eingestellt erhalte ich die Fehler für Pakete, die über dieser Größe und offensichtlich nicht bekommen, die Fehler für Pakete unter dieser Größe.

So scheint es, als ob bei irgendetwas unter 16M das Paket Limit befolgt wird, aber 16M oder größer und es wird vollständig ignoriert.

Irgendwelche Gedanken, was könnte das verursachen? Es ist wirklich bizarr und das gegenteilige Problem, das die meisten Leute mit max_allowed_packet haben.

Ist es möglich, dass der MySQL-Client einige Auto-Chunking durchführen könnte? Der Server scheint nur eine große Abfrage auszuführen, so dass Auto-Chunking wirklich unwahrscheinlich erscheint, da es wahrscheinlich als mehr als eine Einfügung angezeigt wird.

Alle Variablen, die ich überprüfen könnte, um mehr Informationen über das, was vor sich geht, zu erhalten?

Answer 1

Ich habe dies als MySQL-Bug gemeldet und es wurde verifiziert. Also, das ist das jetzt.

Es ist ein Problem in 5.1.52 und höher.

Bugreport hier: http://bugs.mysql.com/58887

Answer 2

Was steckst du ein? Wenn es sich um alles andere als sehr große BLOBs handelt, hat max_allowed_packet keinen Effekt.

Die Nachricht für reguläre Felder wird wie für Netzwerkprotokolle üblich aufgeteilt und neu zusammengesetzt. Der Parameter ist für die Kommunikation von BLOB-Feldern vorgesehen. Siehe documentation.