| Bug #20434 | Inconsistency for max_allowed_packet | ||
|---|---|---|---|
| Submitted: | 13 Jun 2006 16:41 | Modified: | 9 Nov 2006 16:20 |
| Reporter: | Lars Thalmann | Email Updates: | |
| Status: | Not a Bug | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | OS: | Any (any) | |
| Assigned to: | Lars Thalmann | CPU Architecture: | Any |
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.038 sec. using MySQL 8.0.37-u3-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.
© 2025, Oracle Corporation and/or its affiliates
Description: Problem - Session max_allowed_packet can be bigger than global max_allowed_packet. When this happens, large events can be stored in binlog by master, but master can not read them. Current documentation * `max_allowed_packet' The maximum size of one packet or any generated/intermediate string. The packet message buffer is initialized to `net_buffer_length' bytes, but can grow up to `max_allowed_packet' bytes when needed. This value by default is small, to catch large (possibly incorrect) packets. You must increase this value if you are using large `BLOB' columns or long strings. It should be as big as the biggest `BLOB' you want to use. The protocol limit for `max_allowed_packet' is 1GB. Also see BUG#15937. How to repeat: Set local connection thread's max_allowed_packet to > global max_allowed_packet. Suggested fix: Suggested solution - Let dump thread use the maximum value (1GB). - Let the slave always use 1 GB for slave connection. - Let clients connections on master use local max_allowed_packet up to 1GB minus the size of the biggest replication header possible.