数据库同步

发布于 2024-11-17 03:26:19 字数 228 浏览 3 评论 0原文

我正在开发的系统存在一些问题。我有一个 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

许一世地老天荒 2024-11-24 03:26:19

您希望系统中的两个操作(OP:虚拟软件中的操作;WDB:写入数据库)是原子的(要么都发生,要么都不发生)。一种分布式事务,但您的虚拟化软件并不直接支持可事务行为(无回滚)。如果您可以使它们成为某些分布式事务系统的一部分,那么您就完成了(请参阅eg),但这通常是不可能或不切实际的。实现伪事务行为的不同策略取决于您的场景的具体情况。一些示例:


  1. 打开 TX(DB 中的事务)
  2. WDB
  3. OP
  4. 如果 OP 成功,则提交 TX,否则回滚 TX。

仅当写入数据库的内容不依赖于 OP 操作时才可行(不可能)。


  1. OP1(操作的第一阶段:您得到结果,但不要更改任何内容)
  2. 打开 TX
  3. WDB
  4. OP2(第二阶段:您修改 virt. 软件)
  5. 提交 TX 或回滚

(步骤 4-5 可以切换) 这将是穷人的“两阶段提交”实施。仅当您可以将操作分为这两个阶段时才可行。


  1. Open TX
  2. Dummy WDB(将虚拟结果写入 DB)
  3. Rollback TX
  4. OP
  5. WDB

这会检查 DB 是否可操作,在尝试实际操作和写入之前执行虚拟写入。可行,但并非万无一失。


  1. OP
  2. WDB
  3. 如果失败:将数据保存到原始文件,记录错误,向 IT 发送邮件,打开红灯。

听起来很可悲……但有时这是唯一可行的方法。

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:


  1. Open TX (transaction in DB)
  2. WDB
  3. OP
  4. If OP succeeded, commit TX, else rollback TX.

Only feasible if what you write to DB does not depend on OP operation (improbable).


  1. OP1 (first phase of the operation: you get the results, but do not alter anything)
  2. Open TX
  3. WDB
  4. OP2 (second phase: you modify the virt. sofware)
  5. Commit TX or rollback

(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.


  1. Open TX
  2. Dummy WDB (write a dummy result to DB)
  3. Rollback TX
  4. OP
  5. WDB

This checks that the DB is operational, doing a dummy writing before attempting the real operation and writing. Feasible, but not foolproof.


  1. OP
  2. WDB
  3. If fail: save data to a raw file, log error, send mail to IT, turn red lights on.

Sound pathetic... but sometimes it's the only feasible way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文