Is this tested with Jepsen?

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.

can you comment on ease of operations between NDB cluster and aero spike? from my experience NDB cluster is pretty difficult. curious if aero is the same.

Ndb is pretty stable if your workload is stable. Most HLRs at network operators around the world run NDB 24x7, so it is the go-to HA OLTP real-time DB. If, however, you start overloading it, it can be temperamental. So, don't treat it like innodb and do full table scans while expecting millisecond PK lookups. I can't really comment on running Aerospike in production, because i haven't done it - just run experiments with it.