reset slave on new master don't remove master.info

[GoogleCodeExporter]

Hi,

I used the last masterha version (0.55 for manager and 0.54 for node) with 
mysql 5.0.51a.

When the master is down, all the configuration switch on the first slave, but 
the file master.info already exist (on new master).

States:
    - Master : down
    - New master : show slave status is empty, master.info exist
    - Slave : show slave status, on the new master.

If I connect on the new master (with the same user like mha) and I execute 
reset slave, the file master.info disapear.

---------------------------------------------------
Configuration:
masterha_default.cnf
[server default]
user=xxxxx
password=xxxxx
ssh_user=root
master_binlog_dir= /var/log/mysql
remote_workdir=/data/log/masterha
remote_host2
ping_interval=3
master_ip_failover_script=/var/mha/scripts/master_ip_failover
shutdown_script= /var/mha/scripts/power_manager
ignore_fail=1

app1.cnf
[server default]
manager_workdir=/var/log/masterha/app1
manager_log=/var/log/masterha/app1/app1.log

[server1]
hostname=xxxxxx
candidate_master=1

[server2]
hostname=xxxxx
candidate_master=1

[server3]
hostname=xxxxx
candidate_master=1

------------------------------------------------
Result in log
Wed Jan 16 15:19:44 2013 - [info] * Phase 5: New master cleanup phase..
Wed Jan 16 15:19:44 2013 - [info]
Wed Jan 16 15:19:44 2013 - [info] Resetting slave info on the new master..
Wed Jan 16 15:19:45 2013 - [info]  xxxxxxxx: Resetting slave info succeeded.
Wed Jan 16 15:19:45 2013 - [info] Master failover to xxxxx(xxxxx:3306) compl
eted successfully.
Wed Jan 16 15:19:45 2013 - [info]
----- Failover Report -----

app1: MySQL Master failover xxxxxxx to xxxxxxxx succeeded

Master xxxxxxxxx is down!

Original issue reported on code.google.com by teyssier...@gmail.com on 16 Jan 2013 at 2:45

[GoogleCodeExporter]

I test it many time, I don't understand why this don't work ?

Thank you for your help and for your tool :-)

Original comment by teyssier...@gmail.com on 16 Jan 2013 at 3:30

[GoogleCodeExporter]

MySQL 5.0.51 is very old. Do you repeat this on latest MySQL (5.0.latest or 
5.1/5.5)?

Original comment by Yoshinor...@gmail.com on 16 Jan 2013 at 3:44

[GoogleCodeExporter]

I try on other serveur in mysql 5.1.66, I have the same problem.
I work with Debian 6.0 and I used .deb to install mha.
The file master.info changed between slave and new master !

Before down on first slave
15
mysql-bin.000019
106
95.211.154.1
replicateur
r@plic@t@ur
3306
60
0

0
------------------
After, the first slave is now new master
15

4

test
r@plic@t@ur
3306
60
0

0
60
0

0

Original comment by teyssier...@gmail.com on 16 Jan 2013 at 3:58

[GoogleCodeExporter]

Prior to MySQL 5.5 RESET SLAVE ALL is not supported so MHA runs RESET SLAVE and 
CHANGE MASTER MASTER_HOST='' instead. The new master.info is kind of a dummy 
file and is not harmful. If you don't like it try MySQL 5.5.

Original comment by Yoshinor...@gmail.com on 16 Jan 2013 at 4:47

[GoogleCodeExporter]

Ok I found why the master.info is still existing. You execute CHANGE MASTER TO 
MASTER_HOST='' after RESET SLAVE, this recreate the master.info file.
I wanted to use master.info to detect if the server is master or slave.
What is the interest to execute the reset before the change slave to master ?
Have you a (easy) solution to detect if the server is slave or master ?

Thank you very much for your reactivity

Original comment by teyssier...@gmail.com on 16 Jan 2013 at 4:55

[GoogleCodeExporter]

Hi,

To check the topology of the replication :
* use the masterha_check_repl
* use one of the Commands :
    * show slave status\G
    * show slave hosts;
* connnect to the virtual_ip which should be on the master, and issue a "SELECT 
@@hostname"

The goal of issuing the CHANGE MASTER to change the runtime, and filesystem 
replication information. In case of restart, the original slave (new master?) 
will not try (and succeed) to connect to the old master, and get some wrong 
events.
I agree that the MHA software could remove the master.info after all, but this 
is not clean, and this is what RESET SLAVE ALL is doing.

This is also why the "reset slave all" command was added in MySQL 5.5.
Joffrey

Original comment by joff...@mariadb.com on 31 Jan 2013 at 6:17