Q: Architectural challenge in NuoDB addressed? Refer to this video:
https://youtu.be/NsI51Mo6r3o?t=18m48s
The video was dated in Sept. 2013. In technology term it is quite outdated. However, in the video it raised several challenges NuoDB had. I wonder did NuoDB improve on the aspects of:


*

*Race condition in the Join process. If nodes are joined in the wrong order, they'll end up in the quiet split-brain mode, and will lose data if rejoined later.

*Race conditions in database creation / schema operation

*Tricky to configure and start the system in an automated way

*When a node crashes, it does not bring back storage manager or transaction manager, means data can all of a sudden become less durable as you could have only 1 or 0 copy of the data.

*During a partition, transactions are blocked due to cpu/storage hauling resource


A: Yeah, that was a while ago – but it was very helpful to our engineering team then.
We did a lot of work to replicate those tests – and fix the problems they exposed.
It's all written up in a series of blog posts. The best place to start is here:
http://dev.nuodb.com/techblog/network-failure-handling-roundup
It's  the umbrella post for the others that build up to the full response
This next post was added a little later so it's not linked in the above series, but it is still relevant:
http://dev.nuodb.com/techblog/testing-network-failure-aws
And with specific regard to your fourth point, about restarting crashed processes,  NuoDB now has the concept of a Managed Database; that just means it has a defined SLA it will adhere to automatically - from Single Host, through Minimally Redundant and Multi-Host to Geo-Distributed. That means the database will restart or replace lost processes automatically to continue to meet its SLA. And you can change the SLA while the database is running. 
