I agree, SQL_SLAVE_SKIP_COUNTER will mess up things.. it make ur data in
so u can do in following way.. :
a stop slave
b.lock the table t1 ( LOCK TABLES t1 READ) on master
c.do export of t1 table. on master
d. import t1 table on slave..
e. start slave
f. UNLOCK TABLES on master
On Wed, Apr 4, 2012 at 3:26 AM, Johan De Meersman <vegivamp@stripped>wrote:
> ----- Original Message -----
> > From: "umapathi b" <umapathi.b@stripped>
> > You may get some duplicate entry errors on the slave and you can
> > resolve them by using this following command ..whenever there is
> > duplicate entry error on the slave.
> > stop slave; SET GLOBAL SQL_SLAVE_SKIP_COUNTER=1; start slave;
> No no no no NOOOOOOOO *hits head against wall*
> SQL_SLAVE_SKIP_COUNTER does not, I repeat: DOES NOT FIX YOUR REPLICATION.
> If I ever get my hands on the idiot who first posted that somewhere I'll
> damn well feed him to a pack of wild RMSes.
> The word SKIP should be a more than subtle hint: it merely SKIPS the
> problematic statement in the replication log. Afterwards, your data is
> still inconsistent, and you now need to manually verify exactly *what* went
> wrong and how to fix it.
> I swear, someday I'm gonna set up an autoresponder with just this in it.
> *grumbles into his sprawling unix beard*
> Bier met grenadyn
> Is als mosterd by den wyn
> Sy die't drinkt, is eene kwezel
> Hy die't drinkt, is ras een ezel
> MySQL Replication Mailing List
> For list archives: http://lists.mysql.com/replication
> To unsubscribe: http://lists.mysql.com/replication
My Blog: http://adminlinux.blogspot.com
My LinkedIn: http://www.linkedin.com/in/profileprabhat