tag:blogger.com,1999:blog-16959946.post3195009539934280496..comments2023-12-09T16:44:47.897+01:00Comments on The Data Charmer: Parallel replication and GTID - A tale of two implementationsGiuseppe Maxiahttp://www.blogger.com/profile/15801583338057324813noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-16959946.post-23235707780326829822015-07-24T14:00:16.118+02:002015-07-24T14:00:16.118+02:00just brilliant!
Probably the best post about the ...just brilliant!<br /><br />Probably the best post about the issue I've seenAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-16959946.post-2546144420563734012013-12-23T00:20:11.203+01:002013-12-23T00:20:11.203+01:00@Wagner, can you elaborate? It is not clear which ...@Wagner, can you elaborate? It is not clear which system you are referring to.Giuseppe Maxiahttps://www.blogger.com/profile/15801583338057324813noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-75413175246360465372013-12-22T23:42:11.630+01:002013-12-22T23:42:11.630+01:00What I'm really missing this time is a way to ...What I'm really missing this time is a way to check if how many transactions were really executed in parallel regardless of slave_parallel_type configurations...any hint on that? Cheers! Wagner Bianchihttps://www.blogger.com/profile/06364950750941668708noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-32382970449784578612013-03-11T22:05:10.903+01:002013-03-11T22:05:10.903+01:00Yes you're right, it is not very user friendly...Yes you're right, it is not very user friendly, yet still friendlier than having to recreate the replication from a database dump if it happens once. <br /><br />Thanks for your post anyway, it lead the way to solve my problem! In order to avoid it the next time, I'll just use users with limited rights to avoid writing in slave databases accidentally.Anonymoushttps://www.blogger.com/profile/01377745592084568544noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-8078185586878324992013-03-11T19:07:57.809+01:002013-03-11T19:07:57.809+01:00Christian,
Thanks for your comment. This method wo...Christian,<br />Thanks for your comment. This method works, although it looks frightfully unfriendly.Giuseppe Maxiahttps://www.blogger.com/profile/15801583338057324813noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-15599386343576334702013-03-11T19:06:24.101+01:002013-03-11T19:06:24.101+01:00I found your post because I had a similar problem ...I found your post because I had a similar problem with error 1062 while using GTID, so the default error skipping did not work.<br /><br />However, I managed to solve the faulty replication on the slave by using the commands found on the <a href="http://dev.mysql.com/doc/refman/5.6/en/replication-gtids-failover.html#replication-gtids-failover-empty" rel="nofollow">manual page about skipping transactions</a>.<br /><br />Your show slave status\G;-log shows the following:<br />Retrieved_Gtid_Set: c3054160-7b4a-11e2-a17e-6c626da07446:1-386581<br /> Executed_Gtid_Set: c3054160-7b4a-11e2-a17e-6c626da07446:1-386580,<br />c90226d2-7b4a-11e2-a17e-6c626da07446:1<br /><br />The GTID that caused the error was <b>c3054160-7b4a-11e2-a17e-6c626da07446:386581</b> (all GTIDs up to 386580 were executed, the log shows that the slave retrieved one more which could not be executed). Even if Retrieved_Gtid_Set showed 1-386586, the faulty GTID would be 386581.<br /><br />Running the following commands on the slave machine (the one that stopped replicating, I ran them in the MySQL Command Line Client) solved the problem for me:<br /><br />SET GTID_NEXT="c3054160-7b4a-11e2-a17e-6c626da07446:386581";<br /><br />BEGIN;<br />COMMIT;<br /><br />SET GTID_NEXT=AUTOMATIC;<br /><br />FLUSH LOGS;<br />PURGE BINARY LOGS TO "mysql-bin.000002";<br />START SLAVE;<br /><br />All GTIDs and commands are adjusted to your problem. Hope this helps!Anonymoushttps://www.blogger.com/profile/01377745592084568544noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-42105309730314717682013-03-11T19:02:50.718+01:002013-03-11T19:02:50.718+01:00This comment has been removed by the author.Anonymoushttps://www.blogger.com/profile/01377745592084568544noreply@blogger.comtag:blogger.com,1999:blog-16959946.post-39001741487490222022013-02-20T22:41:56.019+01:002013-02-20T22:41:56.019+01:00I think you need to somehow figure out how to run ...I think you need to somehow figure out how to run start slave until because you need to skip just one statement. By adding the server_id to the list of servers to ignore you will ignore the error, but also ignore any other queries after it in the replication stream. So you need to figure out how to run one event from that server, then turn skipping off again. Good luck with that :DAnonymousnoreply@blogger.com