MySQL Bugs: #5588: "Lost connection to MySQL server during query (server

Bug #5588	"Lost connection to MySQL server during query (server_errno=2013)" every hour
Submitted:	15 Sep 2004 11:25	Modified:	15 Sep 2005 21:28
Reporter:	Joerg Klein
Status:	Closed
Category:	Server: Replication	Severity:	S3 (Non-critical)
Version:	4.0.21	OS:	Microsoft Windows (win2000)
Assigned to:	Bugs System	Target Version:

Description:
I have a two way replication on 2 servers. A<->B
On each server I have the following entry in the server.err file every hour, if there is
no activity(processing queries) on it alternatively if the position of the log event is
the same as one hour before:
-------------------------------------------------------------------------------
040915  9:36:49 Error reading packet from server: Lost connection to MySQL server during
query (server_errno=2013)
040915  9:36:49 Slave I/O thread: Failed reading log event, reconnecting to retry, log
'obelix-bin.006' position 79
040915  9:36:49 Slave: connected to master 'repl@10.10.10.32:3306',replication resumed in
log 'obelix-bin.006' at position 79
040915 10:36:50 Error reading packet from server: Lost connection to MySQL server during
query (server_errno=2013)
040915 10:36:50 Slave I/O thread: Failed reading log event, reconnecting to retry, log
'obelix-bin.006' position 79
040915 10:36:50 Slave: connected to master 'repl@10.10.10.32:3306',replication resumed in
log 'obelix-bin.006' at position 79
-------------------------------------------------------------------------------

This Error has no impact on the Replication. It works without problems.

How to repeat:
-

Suggested fix:
-

Hi,

Thanks for your bug report!

This is expected behavior.  This reconnection is due to the slave_timeout value which is
set to
3600 seconds by default (1 hour).  This is in place because there are cases where the
master 
may go down and come back up but the slave isn't notified so it stays in waiting on the
same 
connection.  This timeout will cause a reconnection so that a new and working connection
will be 
made.

Best Regards

OK, that's a good idea, but my eventlog and the *.err is full of these messages and it is
more difficult to see if there is a 'real' error on the mysql server.

I would like to be emailed with the solution to this problem when a response is sent.

I agree with Joerg Klein. It's a nuisance to have these entries in the error log when they
are not "real" errors. As a newbie to MySQL replication, where in the docs does it say to
expect these "errors" and where does it say that they are not "errors"? I'm testing out
replication and looking at my logs thinking, how do I fix this?

Hi,
The normal behaviour is indeed to not print any message in case of connection failure if
this failure is because of timeout, which is apparently your case. Maybe something in the
network layer (of MySQL or something else) fails to qualify the disconnection as due to
timeout. It could be specific to Win2000 (on Linux for example, there is no such error
message printed). We'll do one test on Win2000 to see if we can repeat.

Could you please provide your my.ini/my.cnf files for to make
the test on my side.

Thanks in advance.

I verified this on windows 2000 this way:

- start master and slave, both on Windows (2000 if possible, otherwise
any other Windows). Slave should be started with
--slave_net_timeout=1.

- Leave master idle.

- Verify that replication is running (SHOW SLAVE STATUS) and see if
your slave's error log gets filled with error messages.

- If no message, verify that slave I/O thread reconnects every second,
by monitoring SHOW PROCESSLIST on master (should display a new system
thread every second).

For the record, I'm marking here that this is verified on Win2000 and not on Linux:
platform-specific MySQL bug.

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/internals/28893

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/internals/29030

Patch looks ok now.
Before pushing, please verify that this fixes the reported problem on windows. (See
Matthew Lord's comment of how to do this)

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/internals/29421

Fixed in 4.0.27, 4.1.15, 5.0.13

Noted in 4.0.27, 4.1.15, 5.0.13 changelogs.