Bug 582097 - Slave mysql in replication could not catch up with master
Summary: Slave mysql in replication could not catch up with master
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mysql
Version: 5.5
Hardware: x86_64
OS: Linux
low
urgent
Target Milestone: rc
: ---
Assignee: Tom Lane
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-04-14 06:12 UTC by REN Xiaolei
Modified: 2013-03-20 11:39 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-03-20 11:39:34 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description REN Xiaolei 2010-04-14 06:12:05 UTC
Description of problem:
Slave mysql in replication could not catch up with master, it doesn't know that master log has been changed already.

Version-Release number of selected component (if applicable):
Version     : 5.0.77
Release     : 4.el5_4.2
both slave and master

OR
slave  4.el5_4.2
master 4.el5_4.1

How reproducible:

Steps to Reproduce:
1. run 'show master status' on master, and notice the 'Position'
2. run 'show slave status' on slave, and notice the 'Exec_Master_Log_Pos'
3. do some update on master, then again run 'show master status', you will notice the position increased.
4  again, run 'show slave status' on slave, and notice the 'Exec_Master_Log_Pos'
  
Actual results:
'Exec_Master_Log_Pos' on slave is still the number you see in the 2nd step. Check the data, still not changed like how master does.

Expected results:
'Exec_Master_Log_Pos' should be the same number to 'Position' in the 3rd step.

Additional info:
slave>show slave status\G
           Slave_IO_Running: Yes
          Slave_SQL_Running: Yes
      Seconds_Behind_Master: 0
master>show processlist\G
*************************** 1. row ***************************
     Id: 3
   User: repl
   Host: 124.238.xxx.yyy:40045
     db: NULL
Command: Binlog Dump
   Time: 2745
  State: Has sent all binlog to slave; waiting for binlog to be updated
   Info: NULL


And, if you type 'stop slave; start slave;' ,the slave CAN catch up with master.

The slave mysql use 4.el5_4.2,and the master mysql use 4.el5_4.1 will result the same. Maybe 4.el5_4.2 replication slave code sucks?

Comment 1 Honza Horak 2013-03-20 11:39:34 UTC
I am sorry, but it is now too late in the RHEL-5 release cycle. RHEL-5.10 (the next RHEL-5 minor release) is going to be the first production phase 2 [1] release of RHEL-5. Since phase 2 we'll be addressing only security and critical issues.

I've tried to reproduce it in RHEL-6 with mysql-5.1.67-1.el6_3.x86_64 as both master and slave and it works as expected. Since I don't see a problem in RHEL-6, I am closing the bug as NEXTRELEASE. In case you'll encounter this bug in RHEL-6 again, please, re-open the bug report for RHEL-6 component.


Note You need to log in before you can comment on or make changes to this bug.