0

我们有一个在 Kubernetes 中作为 24x7 服务运行的应用程序，我们无法关闭它来运行我们的迁移脚本。我只是想验证 mongock 框架不会干扰我们的应用程序的操作——例如，通过锁定一个集合过长的时间。

我知道这个问题听起来很广泛，因为迁移的影响/效果取决于我们在 ChangeLog/ChangeSets 中编写的代码。

但我想知道 mongock 框架本身是否对 mongo 集合有任何影响，而不是它自己的内部集合（mongockChangeLog 和 mongockLock）

例如，mongok 是否对 mongo 集合持有任何锁，而不是它自己的？

我假设 mongockLock 拥有的锁不会对 mongockChangeLog 以外的任何集合产生影响。

同样，当启用事务时，mongok 是否拥有任何可能影响或影响我们代码拥有的事务的事务？

4

1 回答 1

0

你的机构是对的。Mongock 的锁只是内部的。另外值得知道的是，您可以配置此锁的使用时间、Mongock 等待它的时间、如果它无法获取它以及它将尝试多长时间。所有这些都在Mongock 的文档中

谈到交易，Mongock 将交易完全委托给底层框架。我不完全理解您的问题，但我可以解释 Mongock 提供哪种类型的交易，您可以更好地了解影响。

  • All or nothing : 整个 Mongock 过程被包裹在一个事务中，如果它在任何时候失败，则整个迁移被回滚。（目前提供）
  • Per changeSet（方法）：每个成功执行的changeSet都被提交。如果中途失败，则回滚。（将在版本 5 中提供）
  • Per changeLog (class)：整个changeLog类被包装在一个事务中，所以只有在其所有的changeSets都成功执行后才会提交。（将在版本5中提供）

一般来说，组织迁移的推荐方法是按 changeLog。一个 changeLog 应该代表一个迁移步骤，它不应该被设计成一个特性方法。例如，如果您的模型中有 Client 和 Bill，则不应该为 Client 设计一个 changeLog，而为 Bill 设计另一个，因为随着时间的推移，它们会应用不同的迁移。相反，您应该以 changeLog 代表迁移步骤的方式执行此操作，从而影响整个模型，以便您可以通过 changeLogs 识别迁移历史记录。从这个角度来看，Mongock 的最佳实践是使用per changeLog事务

于 2021-02-26T11:39:18.147 回答