高可用性架构
我有这样的场景：
您有一条 24/7 运行的工厂生产线。停机时间的成本极其高昂。 控制所有不同部分的软件必须使用共享的数据库存储形式 这样做的主要原因是要了解工厂处于哪种状态。例如，某些产品在使用同一套设备时可以混合，而其他产品则绝对不能混合。
要求：
- 我希望软件能够检测到某一部分的错误 该工厂必定会导致 1 公里以外的部分机器停机。因此，将数据存储在 PLC 中不是一种选择。
- 工厂环境的更新和升级频繁，
- 负载（以计算机术语来说）会非常低。
该系统每天处理数百项任务，完成计算/检查，然后向工厂机器发送指令。大多数时候系统都会感到无聊。最重要的要求是中央计算机系统必须正确且始终工作。
我正在考虑使用基于发电机的数据库（riak 或 cassandra），其中数据被写入多台机器，每台机器都有整个数据库，
当一个系统出现故障时，它会被忽视。当表发生变化时，传统的 sql 数据库升级可能会更加困难，并且主从更难配置。
你的解决方案是什么？
网络已变得冗余，大多数其他单点故障也已消除。数据库系统至关重要，因为数据库的停机意味着整个工厂的停机，而不仅仅是一台机器的停机，这是可以接受的。
- 如何解决共享状态问题。
- 数据库的复杂性不会成为问题。我将更像是一个简单的键值存储来获取最新且正确的数据。
I have this scenario:
You have a factory process line which runs 24/7. Downtime is extremely expensive.
The software controlling all different parts must use a shared form of database storage
The main reason for this is to know in which state the factory is in. For example some products can be mixed when using the same set of equipement and others DEFINITELY not.
requirements:
- I want to the software be able to detect that an error in one part of
the plant must result in some machine shutdown more then 1 km away. so stoing data in the plc's is not an option. - Updates and upgrades to the factory environment are frequent
- load (in computer terms) will be really low.
The systems handles a few hunderd assignments a day for which calculations / checks are done followed by instructions send for the factory machines. Systems will be bored most of the time. Most important requirement is the central computer system must be correct and always working.
I was thinking to use a dynamo based database (riak or cassandra) where data gets written to multiple machines with each machine having the whole database
When one system goes down it will go down unoticed. A Traditional sql databse might be more of a pain to upgrade when tables changes and this master slave is harder to configure.
What would be your solution?
Network has been made redundant and most other single points of failure to. The database system is critical because downtime of the db means downtime for the entire plant not just one of the machines which is acceptable.
- How to solve shared state problem.
- complexity in the database will not be a problem. I will be more like a simple key value store to get the most current and correct data.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不认为这是一个 sql/nosql 问题。所有 Postgres、MySQL 和 MS SQL Server 都有某种集群或热备用选项。
配置是一次性的事情，但是如果您试图在一个为了运行事物而放弃关系的平台上做一些基本相关的事情，那么任何 NoSQL 选项都会让您从头到尾的代码感到头疼像亚马逊或脸书。配置是一次，编码是永久的。
所以我想说坚持使用经过验证的真实解决方案并让热复制继续进行。
这也为升级提供了解决方案。典型的顺序是“故障转移”到备用数据库、升级主数据库、切换回主数据库、升级备用数据库，然后恢复。当然具体情况要根据具体情况而定。
I don't think this is a sql/nosql question. All of Postgres, MySQL and MS SQL Server have some kind of cluster or hot standby option.
Configuration is a one-time thing, but any NoSQL option is going to give you headaches from top-to-bottom of code, if you are trying to do something fundamentally relational on a platform that has given up relational for the purposes of running things like Amazon or Facebook. The configuration is once, the coding is forever.
So I would say stick with a tried and true solution and get that hot replication going.
This also provides a solution for upgrades. The typical sequence is to "fail over" to the standby, upgrade the master, flip back to the master, upgrade the standby, and resume. With details specific to the situation of course.
使用本地支持此类事物的已建立的 RDBMS
您真的想在可能在任何时间点都保持一致的事物上运行 24/7 关键任务系统吗？
Use an established RDBMS that supports such things natively
Do you really want to run a 24/7 mission critical system on something that may be consistent at any point in time?
您需要避免单点故障。
数据库管理系统领域的所有主要参与者都至少提供一种方法来避免数据库本身成为单点故障。我可能会质疑他们是否能够足够快地为您的制造流程传播变化。 （或者数据更新并不是真正的问题？无法从您的问题中真正看出。）我在制造业的数据库工作仅限于汽车和化学工业。微秒对他们来说并不重要。
但数据库管理系统并不是唯一可能失败的东西。 “始终工作”意味着客户也必须始终工作。客户端硬件、网络连接、网络和网络服务器本身都可能存在单点故障。容错服务器有多个电源、多个网卡等，
“永远工作”确实很昂贵。我有一种感觉，数据库不会成为你们公司最大的问题。
You need to avoid single points of failure.
All the major players in our dbms world offer at least one way to avoid making the database itself a single point of failure. I might question whether they can propagate changes fast enough for your manufacturing processes. (Or is data update not really an issue? Can't really tell from your question.) My db work in manufacturing is limited to the car and the chemical industry. Microseconds didn't matter to them.
But the dbms isn't the only thing that can fail. "Always working" means that the clients have to always be working, too. Client hardware, connections to the network, the network and network servers themselves all probably have single points of failure. Failure-tolerant servers have multiple power supplies, multiple NICs, etc.
"Always working" is really expensive. I have a feeling that the database isn't going to be the biggest problem for your company.