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:
None 
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
Description:
mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Connecting to master
                  Master_Host: ndb18
                  Master_User: test
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File:
          Read_Master_Log_Pos: 4
               Relay_Log_File: ndb20-relay-bin.000002
                Relay_Log_Pos: 4
        Relay_Master_Log_File:
             Slave_IO_Running: No
            Slave_SQL_Running: Yes
:
:
                Last_IO_Errno: 2013
                Last_IO_Error: error connecting to master 'test@ndb18:3306' - retry-time: 60  retries: 86400

mysql> STOP SLAVE;
Query OK, 0 rows affected (0.00 sec)

mysql> CHANGE MASTER TO    MASTER_HOST='ndb18',  MASTER_PORT=15001;
Query OK, 0 rows affected (0.06 sec)

mysql> start slave;
Query OK, 0 rows affected (0.01 sec)

*************************** 1. row ***************************
               Slave_IO_State: Waiting for master to send event
                  Master_Host: ndb18
                  Master_User: test
                  Master_Port: 15001
                Connect_Retry: 60
              Master_Log_File: ndb18-bin.000001
          Read_Master_Log_Pos: 106
               Relay_Log_File: ndb20-relay-bin.000002
                Relay_Log_Pos: 251
        Relay_Master_Log_File: ndb18-bin.000001
             Slave_IO_Running: Yes
            Slave_SQL_Running: Yes

mysql> stop slave;
Query OK, 0 rows affected (0.01 sec)

mysql> reset slave;
Query OK, 0 rows affected (0.09 sec)

mysql> start slave;
Query OK, 0 rows affected (0.04 sec)

mysql> show slave status\G
*************************** 1. row ***************************
               Slave_IO_State: Connecting to master
                  Master_Host: ndb18
                  Master_User: test
                  Master_Port: 3306
                Connect_Retry: 60
              Master_Log_File:
          Read_Master_Log_Pos: 4
               Relay_Log_File: ndb20-relay-bin.000002
                Relay_Log_Pos: 4
        Relay_Master_Log_File:
             Slave_IO_Running: No
            Slave_SQL_Running: Yes

How to repeat:
start slave with default settings

#1
STOP SLAVE
CHANGE MASTER
RESET SLAVE
START SLAVE

#2
STOP SLAVE
RESET SLAVE
CHANGE MASTER
START SLAVE

#3
STOP SLAVE
CHANGE MASTER
START SLAVE

STOP SLAVE
RESET SLAVE
START SLAVE

Suggested fix:
Once a CHANGE MASTER has been issued, any RESET SLAVE commands should honor the new setting until such time as new CHANGE MASTER is issued. RESET should then honor then new settings.
[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.