bmildren/resource-agents — comment on commit 72031e5a6a644ce6d9a1ed2ec31d4dfb9bae294b
File:  line 0
By bmildren:

Hi Yves,

I just checked again and the behaviour hasn't changed. The resource
agent currently uses "CHANGE MASTER TO MASTER_HOST=''" in the
unset_master function, and as was noted this will fail in 5.5.
Using "RESET SLAVE;" as an alternative will remove the master.info
file, but the key point is until the MySQL service is restarted, MySQL
will still return a resultset for "SHOW SLAVE STATUS;" including the
old master_host, etc.
The resource agent is_slave() function defines a slave by a non empty
resultset for "SHOW SLAVE STATUS;", so even though RESET SLAVE clears
the master.info file, as a resultset is returned the MySQL instance
will still be defined as a slave, and subsequent functions such as
get_slave_info() will pull junk values.
The dirty hack I had in the commit, was to set
MASTER_HOST='dummy-host-val', this allowed the is_slave() function to
still differentiate the "SHOW SLAVE STATUS;" during the period
unset_master function has been called and the mysql service hasn't
been restarted. I'm sure there's probably a better way, but it served
the purpose at the time.

Hope this helps
Ben

On 7 December 2011 14:32, Yves Trudeau

wrote:
> On 11-12-07 09:21 AM, raoulbhatia wrote:
>> yves, did you find the time to double check?
>>
>> ---
>> Reply to this email directly or view it on GitHub:
>> https://github.com/bmildren/resource-agents/commit/72031e5a6a644ce6d9a1ed2ec31d4dfb9bae294b#commitcomment-775877
>>
> Hi Raoul,
> yes, mysql doesn't cache in memory the replication info, when the IO
> thread starts, it reads the master.info file to find how to reconnect.
> Since reset slave removes master.info, we can say it is forgotten
> completely.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/bmildren/resource-agents/commit/72031e5a6a644ce6d9a1ed2ec31d4dfb9bae294b#commitcomment-775905