It is essentially slave promotion only without mucking with the replication settings. By using a floating IP one machine is effectively always in production (it’s read only for a fraction of a second while the ip is moved). This lets us run alter table on a slave, failover the cluster and run alter table on the other slave without interrupting clients.

The idea behind the floating ip it hat there is no client configuration change to handle failover. The client simply sees a mysql instance at the floating ip that is occasionally read only for a fraction of a second.

-Eric

What we do is run an ALTER on the slave, promote the slave to a master, and then take the old master, and perform the ALTER on it…

This way one machine is always in production.

We actually have three replicas now so it’s slightly more complicated but isomorphic to what I just described.

It also requires no custom code or IP setup……

One downside is that you need to hold a cluster level mutex while you’re doing the promotion. We’re just putting the master in single user mode while this happens which is pretty much the same thing.

Kevin

I have a question thought:
In which ways is it possible to do automatic fail over (for example, in a situation where the active master server crashes). I think it would be very unfortunate to end up in a situation where a server crashes and there’s nobody to do the manual recovery.

Kind regards,
amix