Bug 582097
| Summary: | Slave mysql in replication could not catch up with master | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | REN Xiaolei <julyclyde> |
| Component: | mysql | Assignee: | Tom Lane <tgl> |
| Status: | CLOSED NEXTRELEASE | QA Contact: | qe-baseos-daemons |
| Severity: | urgent | Docs Contact: | |
| Priority: | low | ||
| Version: | 5.5 | CC: | byte, hhorak |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2013-03-20 11:39:34 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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?