Bug #39745 | RESET SLAVE does not honor CHANGE MASTER | ||
---|---|---|---|
Submitted: | 30 Sep 2008 3:17 | Modified: | 19 Nov 2008 17:30 |
Reporter: | Jonathan Miller | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: Documentation | Severity: | S2 (Serious) |
Version: | mysql5.1-telco-6.2 (debug) | OS: | Linux (64 bit ) |
Assigned to: | Jon Stephens | CPU Architecture: | Any |
[30 Sep 2008 3:17]
Jonathan Miller
[1 Oct 2008 7:09]
Andrei Elkin
Jeb, few similar to the report exercises with 6.0 have not shown the problem. However, 5.1 showed. It's the port that is reset to the default 3306. Andrei
[1 Oct 2008 12:42]
Jonathan Miller
5.1 Docs 12.6.2.1. CHANGE MASTER TO Syntax Only section in "change master" talking about reset slave: Issuing RESET SLAVE resets the heartbeat interval to the default. 12.6.2.5. RESET SLAVE Syntax RESET SLAVE RESET SLAVE makes the slave forget its replication position in the master's binary logs. This statement is meant to be used for a clean start: It deletes the master.info and relay-log.info files, all the relay logs, and starts a new relay log. Note All relay logs are deleted, even if they have not been completely executed by the slave SQL thread. (This is a condition likely to exist on a replication slave if you have issued a STOP SLAVE statement or if the slave is highly loaded.) Connection information stored in the master.info file is immediately reset using any values specified in the corresponding startup options. This information includes values such as master host, master port, master user, and master password. If the slave SQL thread was in the middle of replicating temporary tables when it was stopped, and RESET SLAVE is issued, these replicated temporary tables are deleted on the slave. Docs are the same for 6.0
[1 Oct 2008 12:46]
Jonathan Miller
It seems that since we have "change master" now and no-longer allow command line master and port to be passed, then the following is not correct behavior for the "reset slave". Connection information stored in the master.info file is immediately reset using any values specified in the corresponding startup options. This information includes values such as master host, master port, master user, and master password. I would assume the right behavior moving forward would be: RESET SLAVE makes the slave forget its replication position in the master's binary logs. This statement is meant to be used for a clean start: It deletes the relay-log.info files, all the relay logs, and starts a new relay log.
[17 Oct 2008 4:32]
Jonas Oreland
if anyone is interested: i think the triage is wrong. i think the behavior in 6.0 makes reset-slave *useless* so I dont think of this as a feature request, only the you removed one feature (cmd-line-options for replication) and didn't provide any way to accomplish the same. i.e the D-field should have the value "Feature restore request" :-)
[3 Nov 2008 11:25]
Andrei Elkin
Jeb, Jonas, thanks for your input. Answering some concerns, RESET SLAVE does not reset replication parameters responsible for connecting which is along the docs lines. CHANGE MASTER can be issued without master_{port,host,user,password} as those will be taken from the last time CHANGE MASTER was issued mentioning them explicitly. The connection parameters survive RESET SLAVE. Wrt RESET SLAVE to reset the connection parameters as well there had been a mail sent with Subject: voting for CHANGE MASTER behavior - send your votes if any to dev-replication@mysql.com. I'll forward the mail to you guys which will make us to decide upon gathering your votes as well. Thanks! Andrei
[19 Nov 2008 16:42]
Andrei Elkin
As voting on RESET SLAVE resulted in majority confirms the 6.0 behaviour is correct - the command does not really reset the connection info but does reset the stream info - the remaining issue is to correct 6.0 manual lines. The section `Reset Slave' syntax requires changes in this paragraph: Connection information stored in the `master.info' file is immediately reset using any values specified in the corresponding startup options. This information includes values such as master host, master port, master user, and master password. The correct lines can be like these: `RESET SLAVE' no longer changes replication connection parameters such as master host, master port, master user, and master password. Effectively `START SLAVE' can be issued without an intermediate `CHANGE MASTER'. Notice, that the connection parameters are held in the volatile memory and hence they would be reset if the server was shut down.
[19 Nov 2008 17:09]
Jon Stephens
Discussed with Andrei, accepted as Docs bug.
[19 Nov 2008 17:30]
Jon Stephens
Thank you for your bug report. This issue has been addressed in the documentation. The updated documentation will appear on our website shortly, and will be included in the next release of the relevant products.