数据库同步
我正在开发的系统存在一些问题。我有一个 python 脚本,它首先与虚拟化软件一起使用,如果该操作成功,它会将内容写入数据库。 如果虚拟化软件中出现一些异常,那么我可以管理所有事情,但如果插入数据库失败,则会出现真正的问题。如果插入失败,我将不得不恢复虚拟化软件中的内容,否则事情将变得异步。但问题是,不可能一直恢复该软件中的内容。
如何处理以使数据库与该软件保持同步?任何中间件或特殊应用程序???或者编程中有什么逻辑吗?
I have some problem in system I am developing. I have one python script which first works with a virtulisation software and if that operation succeeds, it writes things to database.
If some exception occurs in the virtulisation software then I can manage all things, but the real problem will occur if inserting in database fails. If insert fails , i will have to revert things in that virtulization software otherwise things will become asynchronous. But problem is, reverting things in that software is not possible all the time.
How to handle things so that i can keep the database in sync with that software? Any middle ware or special application??? Or any logic in programming?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
您希望系统中的两个操作(OP:虚拟软件中的操作;WDB:写入数据库)是原子的(要么都发生,要么都不发生)。一种分布式事务,但您的虚拟化软件并不直接支持可事务行为(无回滚)。如果您可以使它们成为某些分布式事务系统的一部分,那么您就完成了(请参阅eg),但这通常是不可能或不切实际的。实现伪事务行为的不同策略取决于您的场景的具体情况。一些示例:
仅当写入数据库的内容不依赖于 OP 操作时才可行(不可能)。
(步骤 4-5 可以切换) 这将是穷人的“两阶段提交”实施。仅当您可以将操作分为这两个阶段时才可行。
这会检查 DB 是否可操作,在尝试实际操作和写入之前执行虚拟写入。可行,但并非万无一失。
听起来很可悲……但有时这是唯一可行的方法。
You want two actions in your system (OP: operation in your virt. software; WDB: write to database) to be atomic (either both take place, or none). Kind of a distributed transaction, but your virtualized software does not directly support directly a transactionable behaviour (no rollback). If you could make them part of some distributed transactional system, you'd be done (see eg), but that is often impossible or impractical. Different strategies to attain a pseudo-transactional behaviour depends on the particulars of your scenario. Some examples:
Only feasible if what you write to DB does not depend on OP operation (improbable).
(Steps 4-5 can be switched) This would be a poor's man "Two-phase commit" implementation. Only feasible if you can divide your operation in those two phases.
This checks that the DB is operational, doing a dummy writing before attempting the real operation and writing. Feasible, but not foolproof.
Sound pathetic... but sometimes it's the only feasible way.