Description:
There is a theoretical possibility for the following scenario
insert t1 values (a=1,b=1)
commit;
update t1 set b = 2 where a = 1;
commit;
select b from t1 where a = 1; // return 1!!!

The select should of course return 2,
This behavior has never been observed wo/ instrumenting code

How to repeat:
see above

Suggested fix:
For committed read to read from primary replica

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/57974

2717 Jonas Oreland	2008-11-06
      ndb - bug#40543 ReadCommitted might theoretically read stale data

Pushed into 5.1.29-ndb-6.3.19  (revid:jonas@mysql.com-20081106100840-fxb98icp0tgzh5ed)
(version source revid:jonas@mysql.com-20081106100948-jdmo3tc971tw2va5) (pib:5)

Pushed into 5.1.29-ndb-6.4.0  (revid:jonas@mysql.com-20081106100840-fxb98icp0tgzh5ed)
(version source revid:jonas@mysql.com-20081106101337-py5fx94c1sfivcca) (pib:5)

Pushed into 5.1.29-ndb-6.2.17  (revid:jonas@mysql.com-20081106100840-fxb98icp0tgzh5ed)
(version source revid:jonas@mysql.com-20081106100840-fxb98icp0tgzh5ed) (pib:5)

Documented in the NDB-6.2.17 and NDB-6.3.19 changelogs as follows:

        It was theoretically possible for stale data to be read from NDBCLUSTER
        tables when the transaction isolation level was set to ReadCommitted.

Pushed into 6.0.9-alpha  (revid:jonas@mysql.com-20081106100840-fxb98icp0tgzh5ed) (version
source revid:tomas.ulin@sun.com-20081209185954-9svcixh2p5hsfi6w) (pib:5)

this commit id is also part of bug fix but has not been tagged as such
d92007e9856801971ba86812861c5778e1d4c69e