Yoshinori Matsunobu <yoshinori@fb.com> writes:

About transaction ids, it's not visible from MyRocks yet. We're currently working on RocksDB to add an API to get transaction id, and making it available via MyRocks.

Ok, I see. Optimistic parallel replication needs the ability to somehow find the THD that is holding the row lock that is blocking another THD. If we have T1 followed by T2, T2 will only commit after T1 has. So if there is a conflicting row lock, we need a way to identify T2 so that the conflict can be resolved. Lock wait timeout is not sufficient here because of the requirement of in-order commit.

Rows are normally released at transaction commit or rollback, but there are some exceptions. - Auto-increment id allocation is implemented as std::atomic<longlong> and the lock is released earlier than statement/transaction, like InnoDB. I hope this doesn't matter for parallel replication, since auto-inc ids are always given on slaves (either RBR image, or insert_id with SBR).

Agree, it does not matter, MyRocks just should not report these lock conflicts with thd_rpl_deadlock_check() (and since this is using a different mechanism, there is no reason it would).

- MyRocks has data dictionary (https://github.com/facebook/mysql-5.6/wiki/MyRocks-data-dictionary-format), and data dictionary operations' transaction scope is different from applications'. For example, internal index id allocation is done (and committed) immediately. There is no SQL statements to directly manipulate data dictionary, so I assume this won't matter for replication either.

Agree, it shouldn't. Optimistic parallel replication handles DDL pessimistically anyway - DDL is not run in parallel with any other statements. Thanks, - Kristian.