Ian P. Christian wrote:
Ofer Inbar wrote:
Assuming your slave is not usable by client programs now anyway and
you don't mind it being unusable for a while longer, you can restart
the slaving from scratch:
This is exactly what I'm trying to avoid doing, it means 2 days downtime
whilst the data is re-inserted.
I have actually managed to fix it now though. I checked the old binary
log from the master, and it had no new data for the slave, so I simply
issued a 'CHANGE MASTER ...' on the slave to tell it to use the new
binary log file, with a position of 4 (the start) and off it when - back
to being in sync.
Now that you are back up, you probably have different data on the master and slave,
from the sounds of it. I've been there, often. I wrote two tools to help solve this
problem without a lot of overhead:
1) take table checksums via replication and discover which tables are
different, if any.
2) efficient syncing of those tables, sending only the changes needed to reconcile
different data, via replication.
Both things need to work through replication, for obvious reasons. Both are available
at http://sourceforge.net/projects/mysqltoolkit. I would be glad to get your feedback
on them.
In practice, this has made it possible for me to re-initialize slaves in minutes
instead of half a day. And as you know, there are lots of things that can go wrong in
replication, so this is a Good Thing.
Cheers
Baron
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
