[Maria-developers] 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
"nanyi607rao" <nanyi607rao@gmail.com> writes:
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
I wonder if this problem is because the code does not detect that trans 1 accesses both primary key values a=1 and a=2? If so, it should be possible to fix. For an UPDATE statement, the row events have both the before image (with a=1) and the after image (with a=2). Maybe there is a bug in the current code that it does not look in the after image? (I am still very interested in adding this feature to MariaDB. Unfortunately I have been too busy with two other big tasks, hopefully once they are done I can get back to this one). - Kristian.
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
participants (3)
-
Kristian Nielsen -
nanyi607rao -
丁奇