NuoDB中的架构挑战得到了解决？

Question

参考此视频： https://youtu.be/NsI51Mo6r3o?t=18m48s

该视频于2013年9月发布。在技术术语中，它已经过时了。然而，在视频中它引发了NuoDB的几个挑战。我想知道NuoDB在以下方面有所改进：

1. 加入过程中的竞争条件。如果节点以错误的顺序连接，它们将以安静的裂脑模式结束，如果以后重新加入则会丢失数据。
2. 数据库创建/架构操作中的竞争条件
3. 以自动方式配置和启动系统的棘手行为
4. 当一个节点崩溃时，它不会带回存储管理器或事务管理器，这意味着数据可能会突然变得不那么持久，因为你只能拥有1或0个数据副本。
5. 在分区期间，由于cpu / storage运输资源而导致交易被阻止

Answer 1

是的，就在不久之前 - 但这对我们的工程团队非常有帮助。 我们做了很多工作来复制这些测试 - 并解决他们暴露的问题。 这一切都写在一系列博客文章中。最好的起点是：

http://dev.nuodb.com/techblog/network-failure-handling-roundup

这是其他人的完整回应

下一篇文章稍后添加，因此在上述系列中没有链接，但它仍然相关：

http://dev.nuodb.com/techblog/testing-network-failure-aws

特别关注你的第四点，关于重新启动崩溃的进程，NuoDB现在具有托管数据库的概念;这只意味着它有一个定义的SLA，它将自动遵守 - 从单一主机，通过最小冗余和多主机到地理分布。这意味着数据库将自动重新启动或替换丢失的进程以继续满足其SLA。您可以在数据库运行时更改SLA。