| Bug #31359 | change_master sets group_master_log_pos twice, ignores future_group_master_log_p | ||
|---|---|---|---|
| Submitted: | 2 Oct 2007 23:25 | Modified: | 6 Feb 2008 22:09 |
| Reporter: | Mark Callaghan | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 5.0.37 | OS: | Any |
| Assigned to: | Andrei Elkin | CPU Architecture: | Any |
| Tags: | change, master, replication | ||
[3 Oct 2007 23:29]
MySQL Verification Team
Thank you for the bug report.
[21 Dec 2007 8:14]
Bugs System
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/commits/40320 ChangeSet@1.2560, 2007-12-21 10:13:54+02:00, aelkin@koti.dsl.inet.fi +1 -0 Bug #31359 change_master sets group_master_log_pos twice, ignores future_group_master_log_p There was a redundant assignement. However, that's the only artifact. Wrt to future_group_master_log_position, there is no issue. The counter is supposed to be set at Log_event::exec_event(). It's used only by Innodb for recovery purposes.
[5 Feb 2008 12:46]
Bugs System
Pushed into 5.0.56
[5 Feb 2008 13:03]
Bugs System
Pushed into 5.1.24-rc
[5 Feb 2008 13:07]
Bugs System
Pushed into 6.0.5-alpha
[6 Feb 2008 22:09]
Jon Stephens
This appear to have no user-visible effects, so I've closed without further action.
Description: change_master in sql_repl.cc has this code sequence. That looks odd to me, why set group_master_log_pos twice and not set future_group_master_log_pos. Should the second assignment be to future_group_master_log_pos? mi->rli.group_master_log_pos = mi->master_log_pos; DBUG_PRINT("info", ("master_log_pos: %lu", (ulong) mi->master_log_pos)); /* Coordinates in rli were spoilt by the 'if (need_relay_log_purge)' block, so restore them to good values. If we left them to ''/0, that would work; but that would fail in the case of 2 successive CHANGE MASTER (without a START SLAVE in between): because first one would set the coords in mi to the good values of those in rli, the set those in rli to ''/0, then second CHANGE MASTER would set the coords in mi to those of rli, i.e. to ''/0: we have lost all copies of the original good coordinates. That's why we always save good coords in rli. */ mi->rli.group_master_log_pos= mi->master_log_pos; How to repeat: Look at the source. Suggested fix: Set future_group_master_log_pos