I don't think so. I believe it would fail quite a few of Jespen's tests, as it is a real-time DB. Typically, you set the transaction deadlock detection timeout to be a couple of seconds. Jepsen thinks transactions can take minutes to complete, and it's ok - the messages are just late. In fact, in NDB, most people think 2PC is a blocking protocol, but it isn't in NDB. If the Transaction Coordinator (TC) fails, there is a quick leader election protocol and a new one takes over failed TCs. Participant failures cause blocking - but only a few seconds (the configured deadlock detection timeout). So, it's behaviour is similar to abortable consensus (aka Paxos), if automatically retry failed transactions.

> Jepsen thinks transactions can take minutes to complete, and it's ok

Jepsen takes great pains to make no assumptions about the time it takes for transactions to execute. We test systems with millisecond-level timeouts, or multi-minute timeouts, and both work fine.

Ok, my mistake. I saw you tried to install NDB several years ago, without any luck. Nowadays, there's mysql cluster mgr, severalnines installer, and we wrote some chef code to automate it. So it's pretty straightforward.