Comments on: When SHOW SLAVE STATUS lies

By: Carole

Carole — Tue, 10 Feb 2009 16:25:21 +0000

Paul, I am using 5.0.45, and have been hunting quite a while for something which properly explained this. You have completely saved me from messing up replication. I followed your example, read my error log carefully, and got everything back up and running. Thank you so very, very much for taking the time to post this.

By: Paul M

Paul M — Mon, 22 Dec 2008 22:40:18 +0000

You would need to post the error log after trying to start the slave, not the whole thing. As it will have more detail as to why the slave SQL thread is running and the slave IO thread has stopped.

By: Avijit

Avijit — Tue, 16 Dec 2008 09:48:36 +0000

Why 2 same database names will come in Binlog_Do_DB col, where I was configured only under [mysqld]

log-bin=mysql-bin
binlog-do-db=test
server-id=1

2. In slave server when I call show slave status\G
it shows
**************************
Slave_IO_State:
Master_Host: 192.168.0.50
Master_User: slave_user
Master_Port: 3306
Connect_Retry: 60
Master_Log_File:
Read_Master_Log_Pos: 4
Relay_Log_File: mysqld-relay-bin.000001
Relay_Log_Pos: 98
Relay_Master_Log_File:
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 98
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
1 row in set (0.00 sec)

Slave_IO_State value is blank. can u please let me know why this happened ? and this is not working at all.
Please revert back with u’r expert comments

By: Simon Mudd

Simon Mudd — Tue, 20 May 2008 13:40:12 +0000

A similar issue, but equally nasty:

http://bugs.mysql.com/bug.php?id=26540

If the slave server crashes (not mysqld process) then the syncronisation point will be lost and can not be recoved. This effectively requires the slave to be rebuilt. Very nasty. MySQL SHOULD be flushing the .info files on every commit to ensure consistency.

If not done the difference between the “.info” files and the real committed last transaction can be as long as 30 seconds. When the slave starts up it will try to reapply transactions from 30 seconds previously…

Tell your slaves not to crash and don’t pull the power on them. If they do, you’ll need to rebuild them.

By: Log Buffer #92: a Carnival of the Vanities for DBAs

Log Buffer #92: a Carnival of the Vanities for DBAs — Fri, 11 Apr 2008 16:39:17 +0000

[...] Here on the Pythian Group Blog, Paul Moen posted about a situation in which SHOW SLAVE STATUS lies. [...]

By: paulm

paulm — Tue, 08 Apr 2008 03:53:16 +0000

Hi Harrison,

Thanks for the update. This was MySQL 5.0.41

By: Harrison Fisk

Harrison Fisk — Mon, 07 Apr 2008 13:35:01 +0000

What version was this on?

I recently worked with the replication team to find and fix bugs of this nature. The resulting fixes were pushed into 5.0.54 and 5.1.23, and I haven’t seen one case of SHOW SLAVE STATUS being wrong in this manner since then.

The bugs in question were:

http://bugs.mysql.com/bug.php?id=31190
http://bugs.mysql.com/bug.php?id=12691

Thanks!

By: kamiar kanani

kamiar kanani — Mon, 07 Apr 2008 08:06:49 +0000

I think these are tow different errors, one inside I/O thread and another in sql thread. error related to I/O thread occurred at :
‘mysql-bin.000480â€² position 683976897
and error related to SQL thread at :
â€˜mysql-bin.000480â€² position 126