问题描述
我们有一个在 Kubernetes 中作为 24x7 服务运行的应用程序，我们无法将其关闭以运行我们的迁移脚本。我只是想验证 mongock 框架不会干扰我们应用程序的操作 - 例如，将集合锁定过长的时间。
我知道这个问题听起来很宽泛，因为迁移的影响/效果取决于我们在 ChangeLog/ChangeSets 中编写的代码。
但我想知道 mongock 框架本身是否对 mongo 集合有任何影响，除了它自己的内部集合（mongockChangeLog 和 mongockLock）
例如，mongock 是否持有除自己以外的 mongo 集合的任何锁？
我假设 mongockLock 拥有的锁不会对 mongockChangeLog 以外的任何集合产生影响。
同样，当启用事务时，mongock 是否拥有任何可能影响或影响我们代码拥有的事务的事务？
解决方法
你的机构是对的。 Mongock 的锁只是内部的。同样值得知道的是，您可以配置此锁需要多长时间，Mongock 等待它多长时间，如果它无法获取它以及它将尝试多长时间。 Mongock's documentation
中的所有内容谈到事务，Mongock 将事务完全委托给底层框架。我不完全理解您的问题，但我可以解释 Mongock 提供哪种类型的交易，您可以更好地了解其影响。
- 全有或全无：整个 Mongock 进程都包含在一个事务中，如果在任何时候失败，则整个迁移将回滚。（目前提供）
- Per changeSet（方法）：提交成功执行的每个变更集。如果中途失败，则回滚。（将在版本 5 中提供）
- Per changeLog（类）：整个changeLog类被包裹在一个事务中，所以只有在它的所有changeSet都成功执行后才会被提交。（将在版本5中提供)
一般来说，组织迁移的推荐方式是按 changeLog。 changeLog 应该代表一个迁移步骤，它不应该以功能方法设计。例如，如果你的模型中有 Client 和 Bill，你不应该为 Client 设计一个 changeLog，为 Bill 设计另一个，在它们中包含你随时间应用的不同迁移。相反，您应该以这样一种方式进行，即变更日志代表迁移步骤，影响整个模型，以便您可以通过变更日志识别您的迁移历史。 从这个角度来看，Mongock 的最佳实践是使用 per changeLog 事务