Sql 高可用性体系结构

我有这样一个场景：

您有一条全天候运行的工厂工艺线。停机时间非常昂贵。 控制所有不同部分的软件必须使用共享形式的数据库存储 这样做的主要原因是要知道工厂在哪个州。例如，某些产品在使用同一套设备时可以混合，而其他产品则绝对不能

要求：

• 我希望该软件能够检测到一个错误的一部分 工厂必须导致超过1公里以外的机器停机。因此，在plc中存储数据不是一个选项
• 工厂环境的更新和升级非常频繁
• 负载（用计算机术语）将非常低

该系统每天处理数百份工作，完成计算/检查，然后向工厂机器发送指令。大多数时候，系统都会感到无聊。最重要的要求是中央计算机系统必须正确且始终工作

我在考虑使用一个基于dynamo的数据库（riak或cassandra），其中数据被写入多台机器，而每台机器都拥有整个数据库

当一个系统发生故障时，它将毫无提示地停机。当表发生变化时，升级传统的sql数据库可能会更麻烦，而且这个主从数据库更难配置

你的解决方案是什么

网络已被设置为冗余，其他大多数单点故障也被设置为冗余。数据库系统至关重要，因为数据库的停机意味着整个工厂的停机，而不仅仅是一台机器的停机，这是可以接受的

• 如何解决共享状态问题
• 数据库的复杂性不会成为问题。我将更像一个简单的键值存储，以获得最新和正确的数据

---

我不认为这是一个sql/nosql问题。所有Postgres、MySQL和MS SQL Server都有某种集群或热备用选项
配置是一次性的，但是如果您试图在一个为了运行类似于Amazon或Facebook的东西而放弃了关系的平台上做一些基本的关系型的事情，那么任何NoSQL选项都会让您从代码的上到下感到头疼。配置是一次，编码是永远
因此，我要说的是，坚持使用一种经过验证的真正解决方案，让热复制继续下去

---

这也为升级提供了解决方案。典型的顺序是“故障切换”到备用，升级主设备，翻转到主设备，升级备用设备，然后继续。当然，要根据具体情况提供详细信息。
使用已建立的RDBMS，该RDBMS本机支持这些内容

---

您真的想在任何时间点都可能一致的设备上运行24/7任务关键型系统吗？
您需要避免单点故障
我们的dbms世界中的所有主要参与者都提供了至少一种方法来避免数据库本身成为单点故障。我可能会质疑，他们是否能够以足够快的速度传播变更，以满足您的制造流程。（或者数据更新不是一个真正的问题吗？从你的问题看不出来。）我在制造业的db工作仅限于汽车和化学工业。微秒对他们来说并不重要
但dbms并不是唯一会失败的东西。“始终工作”意味着客户也必须始终工作。客户端硬件、网络连接、网络和网络服务器本身都可能有单点故障。容错服务器具有多个电源、多个NIC等

---

“总是工作”真的很贵。我觉得数据库不会成为贵公司最大的问题。
对于serverfault来说，这可能是一个更好的问题。comI'm split。如果你觉得应该迁移，投票，或者@Stephan可以问。nosql升级有多困难？你能解释一下头痛的部分吗？头痛在代码中。NoSQL及其Map/Reduce专门针对文档，其属性没有固定的结构。如果你正在经营一家工厂，几乎不可能想象你正在做一些面向文档的事情。这些东西是相关的。因此，让人头疼的是，试图将关系需求强制融入面向文档的解决方案。哪些RDBMS支持此类功能？Oracle、SQL Server、Sybase，不确定postgres或MySQL当前数据库的宕机意味着整个工厂的宕机。这需要避免。处于系统“边缘”的系统可能会停机几个小时。我了解数据库停机的情况。我的意思是，24/7硬件和通信可能比24/7数据库更难实现。如今，大多数企业级SQL dbms支持24/7即时操作——热备份、复制、集群等等。