On Mon, 1 May 2006, Kishore Jalleda wrote: > On 5/1/06, Robinson, Eric <[EMAIL PROTECTED]> wrote: > > I ran mysqlcheck against a replication master database and it reported a > > problem with a table, which it corrected. Is the slave now out of sync? > > If so, how do I correct the problem without copying the whole database > > over a slow WAN link? > > > > --Eric > > > > By Default when you run REPAIR or myisamchk --recover , MySQL writes > the changes made to the Binlog , and those will be obviously > replicated to the slave, so if everything went fine with your > myisamck on the master, then your slave is in sync and you don't have > to do anyhthing special on the slave...
This needs a bit clarification. First off, to my knowledge MySQL does not write [data] changes due to a REPAIR statement. Their replication implementation doesn't work that way. Before MySQL 4.1, REPAIR (and for instance OPTIMIZE) statements are not replicated at all, but are done so by default in 4.1 and up. So an important question is what version your MySQL server is. To answer the original posters question: It's hard to say if your slave is out of sync. If your master got corrupted from say hardware failure or if your MySQL daemon died unexpectedly and a REPAIR resulted in modified data, then your replication slave will most likely be out of sync and you will need to give it a fresh data seed. In that case a REPAIR statement on the slave will not fix the data consistency issue. I can't say this for sure, but I would imagine there aren't many scenarios where a REPAIR on a slave would fix consistency issues. Atle - Flying Crocodile Inc, Unix Systems Administrator -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]