[ClusterLabs] Question about MySQL agent behaviour, in particular <resource_name>_mysql_master_IP

Ken Gaillot kgaillot at redhat.com
Fri May 19 12:39:53 EDT 2017

On 05/08/2017 02:02 AM, Les Green wrote:
> Hi All,
> I've recently had an issue when I've needed to add
> <resource_name>_mysql_master_IP to hosts in a MySQL HA cluster as I
> needed to move a running cluster onto a VPN.
> It seems <resource_name>_REPL_INFO is only set when a resource is
> promoted, so as a test, I:
> * Put the system in maintenance mode
> * Manually removed the <resource_name>_REPL_INFO from the CIB
> * Added the appropriate <resource_name>_mysql_master_IP attributes for
> each node.
> * Manually configured MySQL to be using IP based replication
> * Then took the cluster out of maintenance mode.
> The replication continued ok, but as predicted the
> <resource_name>_REPL_INFO was not populated. When putting the current
> master into standby, the slave was promoted correctly and the
> <resource_name>_REPL_INFO populated correctly.
> HOWEVER, while doing this, I noticed in the code, if the master hostname
> changes, the replication for the slave is restarted at the master
> position, not the slave position. See:
> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/mysql#L535
> Why on earth would we ever do this? This seems rife for a disaster of
> lost writes. I feel we should only ever be using the current slave
> position as the start position for a CHANGE MASTER command.
> Can somebody set me straight on this matter? I feel maybe I'm missing
> something significant.
> Cheers, Les

I've never used the mysql agent, but maybe master_log_pos in this case
actually stores the slave position in the master log? If not, you might
want to open an issue at

Here's the commit that added the relevant code:


Interestingly, it says "only 2-node setup is supported". I don't think
that's still true, but I don't know what was involved in the change.

More information about the Users mailing list