Slave plugin showing difference from master in concurrent scenarios

[Patrick Crews]

The slave plugin is showing differences from the master in certain concurrent scenarios
As noted below, the innodb trx log *is* correct - I validated it by creating a SQL dump from the table/log, populating a validation server, and comparing master-slave dumpfiles) This issue appears to be slave-side in either reading or interpreting the log.

perl ./gentest.pl --dsn=dbi:drizzle:host=localhost:port=9306:user=root:password="":database=test --gendata=conf/drizzle/translog_drizzle.zz --grammar=conf/drizzle/translog_concurrent3.yy --queries=25 --threads=2 --sqltrace --debug --Reporter=DrizzleSlavePlugin

master:
./dbqp.py --start-and-exit --drizzled=--innodb.replication-log=true --no-secure-file-priv

slave:
./dbqp.py --drizzled=--plugin-add=slave --drizzled=--slave.config-file=/slave/tests/slave.cnf --start-and-exit

slave.cnf:
master-host=127.0.0.1
master-port=9306
master-user=root
master-pass=''
max-reconnects=10
seconds-between-reconnects=1

Shows this master-slave diff:
# 2011-02-17T13:35:39 Executing diff --unified /tmp//translog_rpl_dump_2768_9306.sql /tmp//translog_rpl_dump_2768_9308.sql
--- /tmp//translog_rpl_dump_2768_9306.sql 2011-02-17 13:35:39.168851600 -0500
+++ /tmp//translog_rpl_dump_2768_9308.sql 2011-02-17 13:35:39.378799302 -0500
@@ -993,7 +993,7 @@
 INSERT INTO `D` VALUES (6,'EYIFF','p',-4187503228524429312,'f','g',237305856,'DEZZX','k','QSLRO','c',9,'',-758317056,'j',50,1233846272,'z','','t','','QDETV',4450119381795471360,1123876864,'');
 INSERT INTO `D` VALUES (NULL,'BDHFU','u',NULL,'f','e',9,'HATPG','SBWHK','v','s',9,'',-873005056,'OVGMC',56,110,'JGOOX','','HVNSQ','','VJCCN',7298927621084020736,-1903755264,'');
 INSERT INTO `D` VALUES (-4177933079316267008,'VNKCF','v',NULL,'q','i',NULL,'BZTFD','XGYZG','a','x',-8245527967761956864,'',NULL,'m',59,1062338560,'k','','GXHJB','','a',1,-2092367872,'');
-INSERT INTO `D` VALUES (0,'MRRNJ','c',NULL,'z','p',NULL,'v','q','i','w',1473802978056994816,'',9,'l',60,3,'h','','r','','JBYDO',2,2,'');
+INSERT INTO `D` VALUES (-3555591905809006592,'MRRNJ','c',NULL,'z','p',NULL,'v','q','i','w',1473802978056994816,'',9,'l',60,3,'h','','r','','JBYDO',2,2,'');
 INSERT INTO `D` VALUES (-2716515000234541056,'ELJHZ','s',NULL,'x','i',1356070912,'KKNFE','l','ENAVU','f',4,'',399376384,'y',61,110,'BRYFH','','VJEZH','','v',8,-1747910656,'');
 INSERT INTO `D` VALUES (-2430536423896514560,'g','f',NULL,'n','p',1,'MOQNG','t','CGTMP','i',-4911175393647525888,'',1,'p',62,5,'OKHPX','','DNHXE','','f',8,3,'');
 INSERT INTO `D` VALUES (0,'k','a',NULL,'h','j',635961344,'g','a','x','x',4895131319975018496,'',NULL,'TVEAP',63,110,'XVGAG','','AOZWI','','h',0,6,'');
@@ -1051,12 +1051,12 @@
 INSERT INTO `D` VALUES (7015200844559679488,'w','o',NULL,'p','n',-1922957312,'LHTEX','c','h','s',2267843887357755392,'',NULL,'u',119,-1002045440,'b','','YPKJH','','JBOWU',8103383104523075584,-1607991296,'');
 INSERT INTO `D` VALUES (8094657380245045248,'AMWIM','i',NULL,'f','f',2,'IMTQO','KJBPU','EMJFX','c',-8678999431896367104,'',9,'CTAID',120,908918784,'LOJOV','','k','','m',2431380848826646528,7,'');
 INSERT INTO `D` VALUES (NULL,'CCQZH','q',NULL,'d','m',4,'q','m','TOJEG','t',3,'',-204275712,'JNDUT',121,0,'JACJH','','JNXID','','BBTCA',8,534380544,'');
-INSERT INTO `D` VALUES (0,'BVWXT','g',NULL,'x','w',7,'y','y','m','d',8932608385912668160,'',1,'OSQUI',122,2,'TJBYG','','v','','p',8,5,'');
+INSERT INTO `D` VALUES (NULL,'BVWXT','g',NULL,'x','w',7,'y','y','m','d',8932608385912668160,'',1,'OSQUI',122,2,'TJBYG','','v','','p',8,5,'');
 INSERT INTO `D` VALUES (NULL,'RQSIE','u',NULL,'a','c',1199767552,'b','f','BZMTQ','v',3,'',NULL,'a',123,110,'b','','HESDY','','l',1286903593521119232,2086666240,'');
-INSERT INTO `D` VALUES (0,'m','v',NULL,'x','d',1510998016,'UQBHH','AMJFM','o','y',3,'',NULL,'e',124,110,'BNXDF','','UAPNT','','MUBKO',2,-535298048,'');
+INSERT INTO `D` VALUES (-2647272155963719680,'m','v',NULL,'x','d',1510998016,'UQBHH','AMJFM','o','y',3,'',NULL,'e',124,110,'BNXDF','','UAPNT','','MUBKO',2,-535298048,'');
 INSERT INTO `D` VALUES (-7318349394477056,'YTXXI','y',NULL,'t','m',5,'KKXQI','o','USZLU','e',-5152399448688558080,'',NULL,'ZUAGX',125,-212336640,'ECLPE','','TFSKG','','t',-7456835083018698752,5,'');
 INSERT INTO `D` VALUES (0,'s','p',NULL,'e','a',1081409536,'SIORL','NMKDH','j','m',4000885318965264384,'',7,'h',126,8,'h','','PWSUP','','n',2,-309723136,'');
-INSERT INTO `D` VALUES (0,'p','p',NULL,'r','d',7,'x','x','g','u',7995015238489473024,'',4,'COFAR',127,6,'FYKIU','','XJHXK','','JKMCD',5,-28377088,'');
+INSERT INTO `D` VALUES (1,'p','p',NULL,'r','d',7,'x','x','g','u',7995015238489473024,'',4,'COFAR',127,6,'FYKIU','','XJHXK','','JKMCD',5,-28377088,'');
 INSERT INTO `D` VALUES (2,'OTGID','h',NULL,'v','n',4,'EUSFM','LQDHZ','x','y',1,'',-56819712,'m',128,7,'BLLOL','','NZJDR','','DJEKO',3,1215823872,'');
 INSERT INTO `D` VALUES (2,'GJXLN','q',NULL,'e','o',7,'u','WYVGV','IXJTW','d',4,'',1612251136,'JVUDF',129,-1017708544,'JXSBB','','ZOVXS','','d',4,-15990784,'');
 INSERT INTO `D` VALUES (3,'t','j',NULL,'l','e',NULL,'g','MRCKQ','g','j',6789739388214444032,'',5,'DTDQV',130,4,'x','','d','','k',8,-1963917312,'');

[Patrick Crews (patrick-crews)]

Will investigate further and report my findings.

[Patrick Crews (patrick-crews)]

The innodb trx log accurately describes the state of the master (verified via creating a SQL dump from the log, populating a validation server, then comparing the dumpfile from this server and the master).

[David Shrewsbury (dshrews)]

Can you isolate it to the transaction(s) that failed?

[Patrick Crews (patrick-crews)]

Sorry for the late reply - email overload.

This is failing on a single UPDATE that isn't in a transaction.

[David Shrewsbury (dshrews)]

Couple of bugs causing this...

1) Race condition between cached max commit_id value - removed this
2) Logic error with use of LIMIT prevented us from getting all events from the master