search

danielcheng007 / tungsten-replicator

Automatically exported from code.google.com/p/tungsten-replicator
0 stars 0 forks source link

Succeeding transaction fragments get wrong service number when using MySQL RBR replication #292

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?

1. Set up star replication with RBR enabled on MySQL. 
2. Run 'sysbench prepare' to add records to the hub of the star.  The number 
added should be at least 10000. 
3. Observe status of remote services on the hub that return data from the 
spokes. 

What is the expected output?

Remote services should skip transactions that originated on the hub.

What do you see instead?

Transactions are applied resulting in primary key violations. 

What is the possible cause?

EventMetadataFilter correctly identifies the assigns the service if there is 
one fragment but fails if there are multiple fragments.  The reason is that the 
first fragment does not have an update to trep_commit_seqno, which we look at 
to determine the service name.  

What is the proposed solution?

Correct EventMetadataFilter.  We may need to provide a little help at the end 
of the first fragment by adding an update to trep_commit_seqno with the 
position of the first fragment.  (This may be a regression.)  

Additional information

In many cases you can work around by using statement replication, as the 
updates tend to be more compact in the log.  This problem was observed in build 
468. 

Use labels and text to provide additional information.

Original issue reported on code.google.com by robert.h...@continuent.com on 23 Jan 2012 at 9:02

GoogleCodeExporter commented 9 years ago

Original comment by robert.h...@continuent.com on 1 Mar 2012 at 9:45

GoogleCodeExporter commented 9 years ago

Original comment by robert.h...@continuent.com on 1 Mar 2012 at 9:46

GoogleCodeExporter commented 9 years ago

Original comment by robert.h...@continuent.com on 20 Sep 2012 at 5:12

GoogleCodeExporter commented 9 years ago 
We're converging on a 2.0.7 release, so moving the ones that can wait to the 
next release.

Original comment by linas.vi...@continuent.com on 9 Jan 2013 at 3:49

GoogleCodeExporter commented 9 years ago 
We'll use 2.1.0 instead of 2.0.8, hence moving the issues.

Original comment by linas.vi...@continuent.com on 27 Mar 2013 at 3:14

GoogleCodeExporter commented 9 years ago 
Robert will check whether this is still actual.

Original comment by linas.vi...@continuent.com on 24 May 2013 at 1:53

GoogleCodeExporter commented 9 years ago 
Have not been heard of any more, might be safe to reduce priority.

Original comment by linas.vi...@continuent.com on 5 Jun 2013 at 1:53

GoogleCodeExporter commented 9 years ago

Original comment by linas.vi...@continuent.com on 7 Jun 2013 at 2:18

GoogleCodeExporter commented 9 years ago 
These will have to wait, unless someone else picks them up.

Original comment by linas.vi...@continuent.com on 4 Jul 2013 at 2:31

GoogleCodeExporter commented 9 years ago

Original comment by linas.vi...@continuent.com on 26 Aug 2013 at 1:54

GoogleCodeExporter commented 9 years ago 
There won't be a 2.1.3.

Original comment by linas.vi...@continuent.com on 17 Sep 2013 at 10:13

GoogleCodeExporter commented 9 years ago

Original comment by linas.vi...@continuent.com on 20 Nov 2013 at 4:02