Thanks, It helped me a lot. I wanted to know 1.. what are the various scenarios where my replication setup can fail? (considering even issues like network failure and server reboot etc). What is the normal procedure to correct the failure when something unpredicted happens? 2.. What are the scenarios where the SQL THREAD stops running and what are the scenarios where the IO THREAD stops running? 3.. Does SQL_SLAVE_SKIP_COUNTER skip the statement of the master binlog from being replicated to the slave relay log OR Has the statement already been copied into the slave relay log and has been skipped from the relay log? 4.. How do I know immediately that replication has failed? ( have heard that the enterprise edition has some technique for this )? Thanks & regards, Ratheesh
----- Original Message ----- From: "Jan Kirchhoff" <[EMAIL PROTECTED]> To: "Ratheesh K J" <[EMAIL PROTECTED]> Cc: <mysql@lists.mysql.com> Sent: Tuesday, October 02, 2007 4:16 PM Subject: Re: [Replication] - urgent > Ratheesh K J schrieb: >> Hello all, >> >> I issued a create table statement on the master for a table which was not >> present on the master but present on the slave. >> I did this purposely to see the error on slave. >> >> I am a newbie to replication. Now when i see SLave status on the slave >> machine it shows that the SQL Thread has stopped. >> >> When I start the SQL thread it does not start and gives the error message >> that the table exists. How do i correct this and how do I calculate the next >> position that the slave must start executing from the relay log. >> >> Is there any article on MySQL replication that tells me how to deal when >> errors occur. >> >> Thanks & regards, >> Ratheesh >> > > You have 2 options: > > 1. > on the slave, enter "SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1;" and then > "SLAVE START;" on the slave. This skips the upcoming entry in the binlog > which is the create table command that causes your problem. > > 2. > if you don't have any data in the table on the slave, just drop the > table and do a "slave start;", it will then create the table again as > this is the next command in the binlog. > > Remember: never write on the slave without knowing what you do and > you'll be happy with your replication ;) > > Jan
