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

Les Green les at greemo.com
Mon May 8 03:02:24 EDT 2017


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





More information about the Users mailing list