Description:
Scenario 1: in my.cnf configure the following settings:
--------
server-id=<someserverid>
master_host='<hostname>'
master_port=<portofmaster>
master_user=<userid>
master_password=<pwd>
--------
Then, issue the following on the slave:
STOP SLAVE; RESET SLAVE;
Observe what happens (among other things):
- relay-log.info deleted
- master.info deleted
Now, restart the slave (START SLAVE;), wait 20 seconds for the slave to sort itself out, then check the contents of the files:
---------------------
roel@roel-ubuntu-vm:/rep/5136/slave/data$ cat master.info
15
mysql-bin.000001
106
<hostname>
<userid>
<pwd>
<portofmaster>
60
0
0
roel@roel-ubuntu-vm:/rep/5136/slave/data$ cat relay-log.info
./roel-ubuntu-vm-relay-bin.000003
251
mysql-bin.000001
106
---------------------
Scenario 2: stop the server, remove all the my.cnf settings above (except for server-id) and restart the slave. Check that slave is working fine using SHOW SLAVE STATUS.
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Now, issue another STOP SLAVE; RESET SLAVE;
The same happens (relay-log.info deleted, master.info deleted)
Restart the slave with START SLAVE; and check the files again
---------------------
roel@roel-ubuntu-vm:/rep/5136/slave/data$ cat master.info
15
/* << Master_log_file was lost */
4 /* << Read_Master_Log_pos was lost */
<hostname> /* << the host **is reused** */
test /* << the userid resets to 'test' */
<pwd> /* << the password **is reused** */
3306 /* << the port resets to 3306 */
60
0
0
roel@roel-ubuntu-vm:/rep/5136/slave/data$ cat relay-log.info
./roel-ubuntu-vm-relay-bin.000002
4
0
0
---------------------
SHOW SLAVE STATUS at this point:
---------------------
mysql> show slave status\G
*************************** 1. row ***************************
Slave_IO_State: Connecting to master
Master_Host: <hostname>
Master_User: test
Master_Port: 3306
Connect_Retry: 60
Master_Log_File: /* << Master_log_file was lost */
Read_Master_Log_Pos: 4 /* << Read_Master_Log_pos was lost */
Relay_Log_File: roel-ubuntu-vm-relay-bin.000002
Relay_Log_Pos: 4
Relay_Master_Log_File:
Slave_IO_Running: No
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Replicate_Do_Table:
Replicate_Ignore_Table:
Replicate_Wild_Do_Table:
Replicate_Wild_Ignore_Table:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 0
Relay_Log_Space: 106
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: NULL
Master_SSL_Verify_Server_Cert: No
Last_IO_Errno: 2013
Last_IO_Error: error connecting to master 'test@roel-ubuntu-vm:3306' - retry-time: 60 retries: 86400
Last_SQL_Errno: 0
Last_SQL_Error:
1 row in set (0.00 sec)
---------------------
How to repeat:
Recreate scenario 1 / scenario 2 as per the above.
Suggested fix:
If scenario 1 works correctly, scenario 2 should be able to do the same. In scenario 1, it seems like the settings are re-read from the my.cnf file. In both scenario's the server is never restarted. As such, it should be possible to make scenario 2 work in exactly the same way as scenario 1 (and it already partly does: the hostname and password of the master are preserved) by storing such values in memory and re-retrieving them when a START SLAVE is issued after a RESET SLAVE.
If for some reason (though I cannot see one) this is not the desired procedure/result (to have scenario 2 work in the same way as scenario 1) then instead all things should be cleaned up properly (i.e. no 'test' user, no port 3306, no storing of the previous master hostname, no storing of the previous password).