BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET
Problem ======== Replication breaks in the cases if the event length exceeds the size of master Dump thread's max_allowed_packet. The reason why this failure is occuring is because the event length is more than the total size of the max_allowed_packet, on addition of the max_event_header length exceeds the max_allowed_packet of the DUMP thread. This causes the Dump thread to break replication and throw an error. That can happen e.g with row-based replication in Update_rows event. Fix ==== The problem is fixed in 2 steps: 1.) The Dump thread limit to read event is increased to the upper limit i.e. Dump thread reads whatever gets logged in the binary log. 2.) On the slave side we increase the the max_allowed_packet for the slave's threads (IO/SQL) by increasing it to 1GB. This is done using the new server option (slave_max_allowed_packet) included, is used to regulate the max_allowed_packet of the slave thread (IO/SQL) by the DBA, and facilitates the sending of large packets from the master to the slave. This causes the large packets to be received by the slave and apply it successfully. sql/log_event.cc: The max_allowed_packet is not evaluated to the new option slave_max_allowed_packet after the fix. sql/log_event.h: Added the new option in the log_event.h file. sql/mysqld.cc: Added a new option to the server. sql/slave.cc: Increasing the session max_allowed_packet to a large value, i.e. not taking global(max_allowed) into consideration, for the slave's threads. sql/sql_repl.cc: The dump thread's max_allowed_packet is set to the upper limit which makes it independent and it now reads whatever gets logged in the binary log.
Showing
Please register or sign in to comment