Michael, I have been running tests on 4.0.6 with big insert transactions on Linux. I set max_binlog_size to 2M and max_packet_size to 16M. So far no errors with tables up to 400 MB in size.
Looks like MySQL always writes a big transaction as one big block to the current binlog file, and does not cut the binlog file into 2 MB pieces. Thus, it looks like the binlog file rotation cannot be the source of the bug you have observed. If you look in the datadir with ls -l the actual sizes of the master's binlogs, could it be that there really is a 1.3 GB file there? Can you make a script which would always repeat the replication failure? What is the CREATE TABLE statement of your table? What is your my.cnf like? Regards, Heikki ----- Original Message ----- From: "Heikki Tuuri" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, November 28, 2002 1:27 PM Subject: Re: Bug Report: Replication in 4.0.5beta > Michael, > > ----- Original Message ----- > From: "Michael Ryan" <[EMAIL PROTECTED]> > Newsgroups: mailing.database.mysql > Sent: Thursday, November 28, 2002 12:34 PM > Subject: Bug Report: Replication in 4.0.5beta > > > > The environment info was copied from the "mysqlbug" command by our > external > > hosting company who truncated the lines therefore the last couple of > > characters from each line is not there however it was a Solaris 2.8 binary > > download of 4.0.5beta so you would have all of the info anyway. > > > > >Description: > > I am using MySQL 4.0.5beta on Solaris 2.8 from a binary version > > downloaded from www.mysql.com on the 19th of November 2002. I have one > > database set up as the master database and 2 databases set up as slave > > databases. Each database is on a separate SUN server. I am performing > > intense load testing on MySQL replicated databases using InnoDB tables and > > transactions and I have come across what is most likely a bug. > > > > The replication is failing on the slaves with the following error (this > > appears both slaves error logs at the same time) :- > > > > 021127 13:48:28 Error in Log_event::read_log_event(): 'Event too big', > > data_len=1397639424,event_type=111 > > 021127 13:55:36 Error in Log_event::read_log_event(): 'Event too big', > > data_len=1397639424,event_type=111 > > > this definitely looks like a bug in replication. > > From New Zealand we got the following bug report, which might be connected > to this: > > > > > > 021111 18:32:54 Error reading packet from server: log > > event entry > > > > > exceeded max_allowed_packet - increase > > max_allowed_packet on master > > > > > (server_errno=2000) > > Above errors might happen if the pointer to the binlog becomes displaced. It > will then read garbage from the event length field. > > I think a transaction can consist of many log events. > > I will run tests on our SunOS-5.8 computer to see if I can repeat this bug. > > > Best regards, > > Heikki Tuuri > Innobase Oy > --- > InnoDB - transactions, hot backup, and foreign key support for MySQL > See http://www.innodb.com, download MySQL-Max from http://www.mysql.com > > sql query > > ... > > > > BBCi at http://www.bbc.co.uk/ > > > > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
