[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