Sergey, Yoshinori, it was great talking to you about MyRocks in Amsterdam. I took a first look at how to extend MyRocks to work with optimistic parallel replication. It looks conceptually quite simple. Sergey, I understand you have more pressing priorities right now (like getting a tree to build :), so let us revisit this in more detail when you get to it. It looks like the fix is conceptually as simple as this patch, which calls thd_rpl_deadlock_check() whenever a transaction is blocked on a row lock: ----------------------------------------------------------------------- diff --git a/utilities/transactions/transaction_lock_mgr.cc b/utilities/transactions/transaction_lock_mgr.cc index 28e8598..5ff291f 100644 --- a/utilities/transactions/transaction_lock_mgr.cc +++ b/utilities/transactions/transaction_lock_mgr.cc @@ -317,6 +317,8 @@ Status TransactionLockMgr::AcquireWithTimeout(LockMap* lock_map, return result; } +extern "C" int thd_rpl_deadlock_check(MYSQL_THD thd, MYSQL_THD other_thd); + // Try to lock this key after we have acquired the mutex. // Sets *expire_time to the expiration time in microseconds // or 0 if no expiration. @@ -340,6 +342,9 @@ Status TransactionLockMgr::AcquireLocked(LockMap* lock_map, lock_info.expiration_time = txn_lock_info.expiration_time; // lock_cnt does not change } else { + THD *blocked_thd = getTHD(txn_lock_info.txn_id); + THD *bloking_thd = getTHD(lock_info.txn_id); + thd_rpl_deadlock_check(blocked_thd, blocking_thd); result = Status::TimedOut(Status::SubCode::kLockTimeout); } } ----------------------------------------------------------------------- A real patch will need some plumbing to put the code in the right place and have the right information available. Ie. probably the thd_rpl_deadlock_check() call will go into an overridden virtual method in ha_rocksdb.cc. I also did not check if/how one can get from txn_id to THD (what is called getTHD() above), I assume it can be implemented reasonably easy if it is not already there? Hints will be appreciated here as I am new to the MyRocks and RocksDB codebases. When are row locks released? I am interested in whether row locks can be released earlier than at transaction commit time. If so, the simple patch above will give false positives, and it might be worth it to investigate ways to not report locks that are released earlier than commit. Eg. in InnoDB, auto-increment locks are released earlier than commit, and thus are not reported. Once something like this is in place, I think optimistic parallel replication should work. In case of a conflict between transactions T1 and T2, thd_rpl_deadlock_check(T1, T2) will be called and will cause T2 to be killed so that T1 can proceed and T2 be re-tried afterwards. So things look good now; let us revisit this when there is a tree to work on. - Kristian.