List:General Discussion« Previous MessageNext Message »
From:Heikki Tuuri Date:December 4 2002 11:42pm
Subject:Re: Bug Report: Replication in 4.0.5beta
View as plain text  
Michael,

I was able to repeat the bug on Linux now.

It seems to happen if I set max_binlog_size to 2M in the SLAVE. The relay
binlog gets split into several 2 MB pieces. It does not happen always, but I
have a randomized test which produces the error in 1 minute.

I was not able to repeat the bug when I had not set the max binlog size in
the slave, in which case I think it defaults to 1 GB.

heikki@hundin:~/mysql-4.0/sql>
mysqld --defaults-file=/home/heikki/slavemy.cnf
021204 23:55:45  InnoDB: Started
mysqld: ready for connections
021204 23:55:45  Slave I/O thread: connected to master
'slaveuser@hundin:3307',
 replication started in log 'FIRST' at position 4
021204 23:57:42  Error in Log_event::read_log_event(): 'Event too big',
data_len
=1447971143,event_type=115
021204 23:58:03  Slave SQL thread: I/O error reading event(errno: -1
cur_log->e
rror: 12)
021204 23:58:03  Error reading relay log event: Aborting slave SQL thread
becaus
e of partial event read
021204 23:58:03  Could not parse log event entry, check the master for
binlog co
rruption
This may also be a network problem, or just a bug in the master or slave
code.
021204 23:58:03  Error running query, slave SQL thread aborted. Fix the
problem,
 and restart the slave SQL thread with "SLAVE START". We stopped at log
'binlog.
002' position 13659061

heikki@hundin:~/data> ls -l
total 51832
-rw-rw----    1 heikki   users    24086965 Dec  4 23:57 binlog.001
-rw-rw----    1 heikki   users    28925234 Dec  4 23:58 binlog.002
-rw-rw----    1 heikki   users          26 Dec  4 23:57 binlog.index
-rw-rw----    1 heikki   users           5 Dec  4 23:55 hundin.pid
drwxr-xr-x    2 heikki   users         619 Sep  5 20:51 mysql
drwxr-xr-x    2 heikki   users         513 Dec  4 23:57 test
heikki@hundin:~/data>



Also, I observed that if I do a big LOAD DATA INFILE when autocommit=1, then
the master splits the master binlog into 2 MB pieces as I have instructed,
and since I have set max packet size to 1M in both master and the slave, the
slave complains:

heikki@hundin:~/mysql-4.0/sql>
mysqld --defaults-file=/home/heikki/slavemy.cnf
021204 23:48:21  InnoDB: Started
mysqld: ready for connections
021204 23:48:21  Slave I/O thread: connected to master
'slaveuser@hundin:3307',
 replication started in log 'FIRST' at position 4
021204 23:52:08  Error reading packet from server: log event entry exceeded
max_
allowed_packet; Increase max_allowed_packet on master (server_errno=1236)
021204 23:52:08  Got fatal error 1236: 'log event entry exceeded
max_allowed_pac
ket; Increase max_allowed_packet on master' from master when reading data
from b
inary log
021204 23:52:08  Slave I/O thread exiting, read up to log 'binlog.002',
position
 4

This does NOT happen if I set AUTOCOMMIT=0.

I think the above should also be fixed. The slave should read the binlog in
smaller pieces, also in the case where AUTOCOMMIT=1.

Yet another problem:

When LOAD DATA INFILE failed in the master (AUTOCOMMIT=1):

mysql> load data infile '/home/heikki/rtdump' into table replt3;
ERROR 1114: The table 'replt3' is full
mysql>

the slave failed like this:

heikki@hundin:~/mysql-4.0/sql> mysqld --defaults-file=~/slavemy.cnf
021204 21:45:35  InnoDB: Started
mysqld: ready for connections
021204 21:45:35  Slave I/O thread: connected to master
'slaveuser@hundin:3307',
 replication started in log 'FIRST' at position 4
021204 22:04:22  Slave: Could not open file '/tmp/SQL_LOAD-2-1-4.data',
error_co
de=2
021204 22:04:22  Error running query, slave SQL thread aborted. Fix the
problem,
 and restart the slave SQL thread with "SLAVE START". We stopped at log
'binlog.
026' position 27

I am forwarding these to the replication developer of MySQL AB. I hope he
can fix these to 4.0.6.

Best regards,

Heikki Tuuri
Innobase Oy
---
InnoDB - transactions, row level locking, and foreign key support for MySQL
See http://www.innodb.com, download MySQL-Max from http://www.mysql.com

sql query

----- Original Message -----
From: "Heikki Tuuri" <Heikki.Tuuri@stripped>
To: <mysql@stripped>; <michael.ryan@stripped>
Sent: Thursday, December 05, 2002 12:24 AM
Subject: Re: Bug Report: Replication in 4.0.5beta


> 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" <Heikki.Tuuri@stripped>
> To: <mysql@stripped>
> Cc: <support@stripped>
> Sent: Thursday, November 28, 2002 1:27 PM
> Subject: Re: Bug Report: Replication in 4.0.5beta
>
>
> > Michael,
> >
> > ----- Original Message -----
> > From: "Michael Ryan" <michael.ryan@stripped>
> > 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/
> > >
> >
> >
>


Thread
Bug Report: Replication in 4.0.5betaMichael Ryan28 Nov
Re: Bug Report: Replication in 4.0.5betaHeikki Tuuri28 Nov
Re: Bug Report: Replication in 4.0.5betaHeikki Tuuri4 Dec
Re: Bug Report: Replication in 4.0.5betaHeikki Tuuri5 Dec