Hi
> My experience with maatkit, especially after running it after doing a
> 'repair table' is that it's pretty one-sided
Yes you choose one side as master and one side as slave - it can even
figure out the other side automatically from the mysql config
The stated goal is to bring this server into sync with the other one
> and you might need to use the --print option to mk-table-sync before
> actually running it a full strength.
Agreed. And perhaps even grep it a bit, filter it, then apply the
updates manually, etc
> I do not know of a way to "Union" missing results with mk-table-sync,
> because it certainly would be useful to keep the data in both tables.
Well run it from both directions, save the --print output and then a
simple "grep -v" on DELETE before running it would seem to get you
close? I think you can force the utility not to delete as well?
Doesn't seem terribly onerous?
Anyway, in this case the OP was talking about taking one server out of
commision - hence by definition this server is the one which should be
sync'ed back to the master which isn't being taken out of service?
Actually in his case, I think another solution would be just to:
a) Shutdown master that you want to keep
b) Note the current master position and copy the DB's somewhere
c) Shutdown the master to be replaced and copy in the files from step b)
d) Bring up both machines with replication stopped (see startup
options). And do a CHANGE MASTER so that they are both going to start
from the correct position (start of the new binlog file should do it in
each case)
e) Start replication and you are up and running again.
This is just a simple summary of restarting replication of course using
a binary copy... However it doesn't take long (usually) and keeps your
circular replication in place
I personally use maatkit to fixup any problems when replication breaks...
Ed W
