Bug #49931 | Incorrect type in read_log_event error | ||
---|---|---|---|
Submitted: | 24 Dec 2009 19:58 | Modified: | 15 Nov 2010 12:01 |
Reporter: | Andrew Hutchings | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
Version: | OS: | Any | |
Assigned to: | Daogang Qu | CPU Architecture: | Any |
[24 Dec 2009 19:58]
Andrew Hutchings
[8 Feb 2010 9:27]
Daogang Qu
Hi Andrew, How to reproduce the bug? Could you share your test case? Thanks!
[8 Feb 2010 10:00]
Andrew Hutchings
Hello Daogang, To reproduce you need: 1. to write an RBR event to the binlog > 1GB in size (a huge blob insert for example) 2. read the binlog with mysqlbinlog -v
[8 Feb 2010 10:04]
Andrew Hutchings
Sorry, that should be > 2GB to see this problem :)
[18 May 2010 10:09]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/108501 3185 Dao-Gang.Qu@sun.com 2010-05-18 Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The MYSQL server can create a row events with size is bigger than 1GB and transmit it successfully. But the slave I/O thread will check the size of the event by the value of 'max_allowed_packet' when reading log event from binlog. The slave SQL thread do the same thing. And the max value of 'max_allowed_packet' is 1073741824. Once the size of a row event is bigger than the max value. It will cause 'Event too large' or 'packet too large' error. To fix the problem to replicate a row event with size is more than 1 GB to slave. The slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. Then the mysqlbinlog will add a new 'binlog-row-event-max-size' option for reading large row event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_log_event.result Test Result for Bug#49931 and Bug#49932 @ mysql-test/suite/rpl/t/rpl_log_event.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/sql_client.cc Added code to make the max_packet_size will take the bigger one the 'net_buffer_length', 'max_allowed_packet' and 'opt_binlog_rows_event_max_size'.
[24 May 2010 5:33]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/108972 3186 Dao-Gang.Qu@sun.com 2010-05-24 Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The MYSQL server can create a row events with size is bigger than 1GB and transmit it successfully. But the slave I/O thread will check the size of the event by the value of 'max_allowed_packet' when reading log event from binlog. The slave SQL thread do the same thing. And the max value of 'max_allowed_packet' is 1073741824. Once the size of a row event is bigger than the max value. It will cause 'Event too large' or 'packet too large' error. To fix the problem to replicate a row event with size is more than 1 GB to slave. The slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. Then the mysqlbinlog will add a new 'binlog-row-event-max-size' option for reading large row event. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one the 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that replicate large row event with its size is more than 1 GB. @ sql/sql_client.cc Restore the code
[24 May 2010 6:29]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/108974 3185 Dao-Gang.Qu@sun.com 2010-05-24 Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The MYSQL server can create a row events with size is bigger than 1GB and transmit it successfully. But the slave I/O thread will check the size of the event by the value of 'max_allowed_packet' when reading log event from binlog. The slave SQL thread do the same thing. And the max value of 'max_allowed_packet' is 1073741824. Once the size of a row event is bigger than the max value. It will cause 'Event too large' or 'packet too large' error. To fix the problem to replicate a row event with size is more than 1 GB to slave. The slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. Then the mysqlbinlog will add a new 'binlog-row-event-max-size' option for reading large row event. ****** Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The MYSQL server can create a row events with size is bigger than 1GB and transmit it successfully. But the slave I/O thread will check the size of the event by the value of 'max_allowed_packet' when reading log event from binlog. The slave SQL thread do the same thing. And the max value of 'max_allowed_packet' is 1073741824. Once the size of a row event is bigger than the max value. It will cause 'Event too large' or 'packet too large' error. To fix the problem to replicate a row event with size is more than 1 GB to slave. The slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. Then the mysqlbinlog will add a new 'binlog-row-event-max-size' option for reading large row event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_log_event.result Test Result for Bug#49931 and Bug#49932 @ mysql-test/suite/rpl/t/rpl_log_event.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one the 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that replicate large row event with its size is more than 1 GB.
[25 May 2010 3:40]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/109110 3185 Dao-Gang.Qu@sun.com 2010-05-25 Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The MYSQL server can create a row events with size is bigger than 1GB and transmit it successfully. But the slave I/O thread will check the size of the event by the value of 'max_allowed_packet' when reading log event from binlog. The slave SQL thread do the same thing. And the max value of 'max_allowed_packet' is 1073741824. Once the size of a row event is bigger than the max value. It will cause 'Event too large' or 'packet too large' error. To fix the problem to replicate a row event with size is more than 1 GB to slave. The slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. Then the mysqlbinlog will add a new 'binlog-row-event-max-size' option for reading large row event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_log_event.result Test Result for Bug#49931 and Bug#49932 @ mysql-test/suite/rpl/t/rpl_log_event.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one the 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that replicate large row event with its size is more than 1 GB.
[25 May 2010 10:05]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/109149 3185 Dao-Gang.Qu@sun.com 2010-05-25 Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The MYSQL server can create a row events with size is bigger than 1GB and transmit it successfully. But the slave I/O thread will check the size of the event by the value of 'max_allowed_packet' when reading log event from binlog. The slave SQL thread do the same thing. And the max value of 'max_allowed_packet' is 1073741824. Once the size of a row event is bigger than the max value. It will cause 'Event too large' or 'packet too large' error. To fix the problem to replicate a row event with size is more than 1 GB to slave. The slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. Then the mysqlbinlog will add a new 'binlog-row-event-max-size' option for reading large row event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_log_event.result Test Result for Bug#49931 and Bug#49932 @ mysql-test/suite/rpl/t/rpl_log_event.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one the 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that replicate large row event with its size is more than 1 GB.
[27 May 2010 8:56]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/109324 3185 Dao-Gang.Qu@sun.com 2010-05-27 Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The size limitation of ROW event is controlled by binlog-row-event-max-size (4G), which can be larger than max-allowed-packet (1G). And the value of max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave IO/SQL thread and mysqlbinlog just check the size of the ROW event by the value of 'max_allowed_packet' when reading log event from binlog. So it will cause 'Event too large' or 'packet too large' error, if the size of ROW event is bigger than the value of 'max_allowed_packet'. To fix the problem, the slave IO/SQL thread and mysqlbinlog will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. And add a new 'binlog-row-event-max-size' (4G by default) option to mysqlbinlog. Then mysqlbinlog can read a large ROW event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result Test Result for Bug#49931 and Bug#49932 @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one the 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that replicate large row event with its size is more than 1 GB.
[27 May 2010 10:43]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/109341 3185 Dao-Gang.Qu@sun.com 2010-05-27 Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The size limitation of ROW event is controlled by binlog-row-event-max-size (4G), which can be larger than max-allowed-packet (1G). And the value of max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave IO/SQL thread and mysqlbinlog just check the size of the ROW event by the value of 'max_allowed_packet' when reading log event from binlog. So it will cause 'Event too large' or 'packet too large' error, if the size of ROW event is bigger than the value of 'max_allowed_packet'. To fix the problem, the slave IO/SQL thread and mysqlbinlog will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. And add a new 'binlog-row-event-max-size' (4G by default) option to mysqlbinlog. Then mysqlbinlog can read a large ROW event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result Test Result for Bug#49931 and Bug#49932 @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one the 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that replicate large row event with its size is more than 1 GB.
[1 Jun 2010 7:04]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/109646 3186 Dao-Gang.Qu@sun.com 2010-06-01 Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The size limitation of ROW event is controlled by binlog-row-event-max-size (4G), which can be larger than max-allowed-packet (1G). And the value of max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave IO/SQL thread and mysqlbinlog just check the size of the ROW event by the value of 'max_allowed_packet' when reading log event from binlog. So it will cause 'Event too large' or 'packet too large' error, if the size of ROW event is bigger than the value of 'max_allowed_packet'. To fix the problem, the slave IO/SQL thread and mysqlbinlog will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. And add a new 'binlog-row-event-max-size' (4G by default) option to mysqlbinlog. Then mysqlbinlog can read a large ROW event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result Test Result for Bug#49931 and Bug#49932. @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one of the values of 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that slave I/O thread can replicate large row event from master.
[1 Jun 2010 7:10]
Daogang Qu
Pushed into mysql-5.1-rep+2.
[1 Jun 2010 9:35]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/109671 3143 Dao-Gang.Qu@sun.com 2010-06-01 [merge] Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The size limitation of ROW event is controlled by binlog-row-event-max-size (4G), which can be larger than max-allowed-packet (1G). And the value of max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave IO/SQL thread and mysqlbinlog just check the size of the ROW event by the value of 'max_allowed_packet' when reading log event from binlog. So it will cause 'Event too large' or 'packet too large' error, if the size of ROW event is bigger than the value of 'max_allowed_packet'. To fix the problem, the slave IO/SQL thread and mysqlbinlog will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. And add a new 'binlog-row-event-max-size' (4G by default) option to mysqlbinlog. Then mysqlbinlog can read a large ROW event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result Test Result for Bug#49931 and Bug#49932. @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one of the values of 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that slave I/O thread can replicate large row event from master.
[1 Jun 2010 9:53]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/109677 2982 Dao-Gang.Qu@sun.com 2010-06-01 [merge] Bug #49931 Incorrect type in read_log_event error Bug #49932 mysqlbinlog max_allowed_packet hard coded to 1GB The size limitation of ROW event is controlled by binlog-row-event-max-size (4G), which can be larger than max-allowed-packet (1G). And the value of max_allowed_packet is hard coded to 1GB in mysqlbinlog. But the slave IO/SQL thread and mysqlbinlog just check the size of the ROW event by the value of 'max_allowed_packet' when reading log event from binlog. So it will cause 'Event too large' or 'packet too large' error, if the size of ROW event is bigger than the value of 'max_allowed_packet'. To fix the problem, the slave IO/SQL thread and mysqlbinlog will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. And add a new 'binlog-row-event-max-size' (4G by default) option to mysqlbinlog. Then mysqlbinlog can read a large ROW event. @ client/mysqlbinlog.cc Added code to add a new 'binlog-row-event-max-size' mysqlbinlog option for reading large row event. @ mysql-test/suite/rpl/r/rpl_row_event_max_size.result Test Result for Bug#49931 and Bug#49932. @ mysql-test/suite/rpl/t/rpl_row_event_max_size.test Added test file to verify if the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog, and the added 'binlog-row-event-max-size' mysqlbinlog option works fine. @ sql/log_event.cc Added code to make the slave I/O thread and slave SQL thread will check the bigger one of the values of 'max_allowed_packet' and 'binlog-row-event-max-size' when reading log event from binlog. @ sql/slave.cc Added code to assign the max_packet_size with the bigger one of the values of 'max_packet_size' and 'opt_binlog_rows_event_max_size'. So that slave I/O thread can replicate large row event from master.
[1 Jun 2010 10:04]
Daogang Qu
Pushed into mysql-5.1-rep+2, mysql-5.1-rep+3 and mysql-next-mr-rpl-merge.
[26 Jun 2010 7:40]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100626073921-t0e6q2c9nkhuemnj) (version source revid:alik@sun.com-20100626073921-t0e6q2c9nkhuemnj) (pib:16)
[4 Aug 2010 8:02]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804080001-bny5271e65xo34ig) (version source revid:alik@sun.com-20100626073921-t0e6q2c9nkhuemnj) (merge vers: 5.6.99-m4) (pib:18)
[4 Aug 2010 8:19]
Bugs System
Pushed into mysql-trunk 5.6.1-m4 (revid:alik@ibmvm-20100804081533-c1d3rbipo9e8rt1s) (version source revid:alik@sun.com-20100626073921-t0e6q2c9nkhuemnj) (merge vers: 5.6.99-m4) (pib:18)
[6 Aug 2010 14:24]
Jon Stephens
No changelog entry needed for 5.6, since this did not appear in any 5.6 release. Waiting for merges to other trees(? -- would help if Version/Target Version fields weren't empty). Set status = NM.
[16 Aug 2010 6:32]
Bugs System
Pushed into mysql-next-mr (revid:alik@sun.com-20100816062819-bluwgdq8q4xysmlg) (version source revid:alik@sun.com-20100816062612-enatdwnv809iw3s9) (pib:20)
[3 Sep 2010 17:26]
Jon Stephens
I set Need Merge status due to PBKAC -- should have been closed.
[13 Nov 2010 16:21]
Bugs System
Pushed into mysql-trunk 5.6.99-m5 (revid:alexander.nozdrin@oracle.com-20101113155825-czmva9kg4n31anmu) (version source revid:vasil.dimov@oracle.com-20100629074804-359l9m9gniauxr94) (merge vers: 5.6.99-m4) (pib:21)
[15 Nov 2010 12:01]
Jon Stephens
Closed. See previous comments.