I agree that it's not the end of the world to restart a mysql process,
but it would be greater if adding a db to the replication could be done
without having to restart it.
The real problem is not restarting the slave, the problem is that the
master has to be restarted also, as both servers are in circular
replication. Here is where the problem starts.
I can reboot the backup one with no problem, but how do I reboot the
active (which is also the master)? I suppose that the obvious would be:
- Restart my2 (backup)
- Switch my1 (active) and my2 (backup)
- Restart my1 (backup)
- Switch my1 and my2
The problem is that these mysql servers work with realtime information,
and the replication is not done in realtime, and we may find
- my1 active, my2 backup
- we do an insert1 to my1
- at this moment my2 turns active and my2 backup
- we delete insert1 information
- insert1 is replicated from my1 to my2
- delete is replicated from my2 to my1
At this point my1 does not contain the information of the insert1
because it has been deleted (it was replicated from my2), but it is
contained in the my2. Now we have an inconsistency...
Rick James wrote:
> Your clients "should" be able to handle the restart.
> * What if there were a network glitch? The clients should be able to
> reconnect when they notice the dropped connection.
> * What if the slave has a disk crash? The clients should automatically
> switch to another slave.
> * What if an earthquake wipes out the data center? Then you need
> replication to a remote site.
> * Etc.
> Adding a line to my.cnf and restarting the slave is minor compared to
> all the other things that can (and eventually will) go wrong.
> By having two (or more) slaves behind a load balancer, one can simply
> (tediously) restart one slave at a time.