![](https://secure.gravatar.com/avatar/99fde0c1dfd216326aae0aff30d493f1.jpg?s=120&d=mm&r=g)
Rich Prohaska
I suspect that the poor slave replication performance for optimistic replication occurs because TokuDB does not implement the kill_query handlerton function. kill_handlerton gets called to resolve lock wait for situations that occur when parallel replicating a small sysbench table. InnoDB implements kill_query while TokuDB does not implement it.
Possibly, but I'm not sure it's that important. The kill will be effective as soon as the wait is over. I'm thinking that it's just because my patch is incomplete - it only handles the case where transaction T1 goes to wait on T2 and T2 is already holding the lock. If the lock is later passed to T3 (while T1 is still waiting), then my patch doesn't handle killing T3. So T1 will need to wait for its lock wait timeout to trigger, and then it will be re-tried - and _then_ T3 will be killed. At least it looks a bit like that is what is happening in your processlist output. But I'll need to do some tests to be sure. And I think I know how to fix my patch, hopefully I'll have something in a day or two.
when slave in conservative mode with 2 threads, the tokudb wait for callback is being called (i put in a "printf"), which implies a parallel lock conflict. I assumed that conservative mode implies parallel execution of transactions that were group committed together, which I assumed would imply that these transactions were conflict free. Obviously not the case.
This is interesting. Is there somewhere I can read details of how TokuDB does lock waits? That would help me understand what is going on. We actually have the same situation in InnoDB in some cases. For example: CREATE TABLE t4 (a INT PRIMARY KEY, b INT, KEY b_idx(b)) ENGINE=InnoDB; INSERT INTO t4 VALUES (1,NULL), (2,2), (3,NULL), (4,4), (5, NULL), (6, 6); UPDATE t4 SET b=NULL WHERE a=6; DELETE FROM t4 WHERE b <= 3; The UPDATE and DELETE may or may not conflict, depending on the order in which they run. So it is possible for them to group commit together on the master, but still conflict on the slave. Maybe something similar is possible in TokuDB? Another option is that some of the callbacks are false positives. Lock waits should only be reported if they are for locks that will be held until COMMIT. For example in InnoDB, there are shorter-lived locks on the auto-increment counter, and such locks should _not_ be reported. - Kristian.