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

Question

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

该视频的日期为 2013 年 9 月。在技术方面它已经过时了。然而，在视频中，它提出了 NuoDB 面临的几个挑战。我想知道 NuoDB 在以下方面是否有所改进：

1. 加入过程中的竞争条件。如果节点以错误的顺序加入，它们将最终进入安静的裂脑模式，并且如果稍后重新加入，则会丢失数据。
2. 数据库创建/架构操作中的竞争条件
3. 难以以自动化方式配置和启动系统
4. 当节点崩溃时，它不会恢复存储管理器或事务管理器，这意味着数据可能会突然变得不那么持久，因为您可能只有 1 个或 0 个数据副本。
5. 在分区期间，事务因 CPU/存储拖运资源而被阻止

Answer 1

是的，那是不久前的事了——但当时它对我们的工程团队非常有帮助。 我们做了很多工作来复制这些测试——并修复它们暴露的问题。 这一切都写在一系列博客文章中。最好的起点是这里：

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

这是建立完整响应的其他人的总括性帖子

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

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

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