maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Yoshinori Matsunobu <yoshinori@xxxxxx> 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.