Re: Need help to review a serializability implementation for MySQL Cluster

[Alex Ou]

A sub-section about mounting a 2nd-tier serializability implementation to MySQL InnoDB's Read-Committed isolation level is up. Since such an implementation got the potential to minimize lock conflicts, it should be able to out-perform MySQL InnoDB's serializable isolation level in some workload, especially those where predicate-based conflicts are sparse.

However, I am having difficulty mounting such an implementation to its Repeatable-Read isolation level. It's explained in this sub-section.

Anyway, we have now three 2nd-tier serializability implementations on three different platforms: NDB Cluster, TiDB and MySQL InnoDB. They all speak the MySQL dialect and can be analyzed with the conflict_parser helper program.

The TiDB team can't address my feature request immediately since 'they only have limited resources'. So the serializability implementation on top of their Snapshot Isolation is the only one we got for now.

Recently, I've received a message from Cockroach's team claiming that the starvation situation in the original timestamp-based serializability implementation can be resolved by a technique called 'read refreshing' they use to choose a timestamp for a transaction. I looked into it and it checks up. It seems it is also possible to mount a 2nd-tier serializability implementation to their Read-Committed isolation level in most cases. I will re-work the sub-section for CockroachDB and present these in a few weeks. It looks like we will have two more weapons in our arsenal soon if things go smoothly.