使用持续运行的应用程序运行 mongock 是否安全？

Question

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

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

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

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

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

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

Answer 1

您的机构是正确的。 Mongock 的锁只是内部的。另外值得知道的是，您可以配置此锁的使用时间、Mongock 等待它的时间、如果它无法获取它以及它将尝试多长时间。这一切都在Mongock's documentation

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

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

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