To restore specific tables (or full databases) I often use this trick (I'm
just writing this down from memory, you would want to run it through a
test environment first). It runs something like this:
1) MASTER: query FLUSH TABLES WITH READ LOCK;
query SHOW MASTER STATUS\G
2) SLAVE:
Yes thats very true, as the corrupt slave would pick up from where it left
and its quite posssible that the record was already updated on the healthy
slave from the master, causing the replication to fail, but having said that
may be you could do this
1) stop the healthy slave
2) put a global read
Hi Folks,
We've got a Single Master/Multiple Slave environment.
Recently, we had some corruption on one of the slaves and I had to
repair the affected tables.
After the repair completed, some of the rows on the slave had been
deleted - so the Master and the Slave weren't exactly in synch.
an rsync with the right options from the unaffected slave to the corrupt
one might prove to be an elegant technique
Kishore Jalleda
On 3/7/06, Michael Jeung [EMAIL PROTECTED] wrote:
Hi Folks,
We've got a Single Master/Multiple Slave environment.
Recently, we had some corruption on one of
Hi Kishore,
That's an interesting idea. However, given that the healthy slave
and the corrupt slave now have different values for
Exec_Master_Log_Pos, would restoring the tables from the healthy
slave necessarily be a good move?
I would be worried that the corrupt slave's counter
