16.4.1.20 Replication and max_allowed_packet

max_allowed_packet sets an
upper limit on the size of any single message between the MySQL
server and clients, including replication slaves. If you are
replicating large column values (such as might be found in
TEXT or
BLOB columns) and
max_allowed_packet is too small
on the master, the master fails with an error, and the slave
shuts down the I/O thread. If
max_allowed_packet is too small
on the slave, this also causes the slave to stop the I/O thread.

Prior to MySQL 5.1.40, Last_IO_Error and
Last_IO_Errno in the output of
SHOW SLAVE STATUS were not set in
the event that replication failed due to exceeding
max_allowed_packet (Bug
#42914).

Row-based replication currently sends all columns and column
values for updated rows from the master to the slave, including
values of columns that were not actually changed by the update.
This means that, when you are replicating large column values
using row-based replication, you must take care to set
max_allowed_packet large enough
to accommodate the largest row in any table to be replicated,
even if you are replicating updates only, or you are inserting
only relatively small values.

User Comments

Ran into a bit of an issue updating max_allowed_packet dynamically on a master/slave pair. I thought I was being smart by updating the slave setting first and then the master but that's not quite enough. The slave immediately reported:

"Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave."

Yikes!. The good news is that it's just your relay logs that are borked, not the master logs. I think this may have something to do with the fact that the max_allowed_packet is not updated for existing connections, only new ones, and the slave needs a bit of a bump to keep it going properly (?).

The solution is to reconfigure the connection to the slave with the RELAY_MASTER_LOG_FILE AND EXEC_MASTER_LOG_POS from SHOW SLAVE STATUS. You just need to plug RELAY_MASTER_LOG_FILE and EXEC_MASTER_LOG_POS into MASTER_LOG_FILE AND MASTER_LOG_POS a CHANGE MASTER TO statement and things should be good to go. Note that you only need to specify those two values (no need to include host, password, etc) as the existing settings will be reused by default.