Hi， Thank you for reporting. This shows you have some degree of understanding this solution :) If fact, the current implementaion do not have the bug you mentioned. Because the binlog of this statement "update t1 set a=2 where a=1;" contains two "image" of the row. So when dispatching the transaction, we consider it contains two primary kyes (1 and 2). So the two transactions in youre example will NOT apply parallely in slave. Because they affect the same primary key (2). Best regards, Dingqi ------------------------------------------------------------------发件人：nanyi607rao <nanyi607rao@gmail.com>发送时间：2013年7月11日(星期四) 12:46收件人：Kristian Nielsen <knielsen@knielsen-hq.org>; 丁奇 <dingqi.lxb@taobao.com>抄 送：maria-developers <maria-developers@lists.launchpad.net>主 题：a bug of ding-qing parallel replication hi guys, I find a bug of ding-qing parallel replication. let's consider a table like this: create table t1( a int(11) NOT NULL DEFAULT '0', b varchar(10), PRIMARY KEY (a) )ENGINE=InnoDB if we do transactions on master(binlog_format=ROW) like this: trans 1: begin; insert into t1 values(1, "tt"); update t1 set a=2 where a=1; commit; trans 2; begin; update t1 set b="kk" where a=2; commit; then this two transactions binlog transmit to the slave, because trans 1 and trnas 2 has different primary keys, it would disaptch in different threads like this: thread 1 do trans 1 thread 2 do trans 2 thread 2 may update t1 before thread 1, then it will fail. maybe thread 2 can retry sever times ,but it don't solve this problem compeletly.. 2013-07-11 nanyi607rao