0

我们正在 Kubernetes 中运行我们的 mongock 脚本。我们的服务 pod 有副本，因此在初始化时，第一个副本获取 mongock 锁，而第二个（和第三个）副本等待轮到它们。mongock 锁按预期工作——一次只运行一个脚本——但在释放锁和下一次执行获取它之间存在时间间隔。在我的测试中，这个间隔大约是 3 分钟。我们有多达 30 个副本，因此这将增加我们 pod 的启动时间的相当大的开销。

这个间隔是“死时间”——即我们的脚本在此期间没有做任何工作。我在我们的日志中验证了第一个脚本执行在下一个副本获取锁之前 3 分钟（左右）释放了锁。

maxWaitingForLockMinutes驱动文档中 有一个设置：https: //www.mongock.io/spring#building-time-driver

如果我将其设置为较低的数字（例如 1 分钟），这会减少第二次执行等待获取锁的时间吗？

我们已经使用 Spring 注解配置了 mongock。我已将这些属性添加到我们的 Springapplication.properties文件中（来自 mongock 在线文档的示例），但似乎 mongock 并未读取它们：

mongock:
  change-log-repository-name: myChangeLogCollectionName
  max-waiting-for-lock-minutes: 1

Spring application.properties 是这些的正确位置吗？

4

2 回答 2

0

正如在单独的线程中所讨论的，该领域的改进已经确定，并将在版本 5 中提供，该版本将在 6 月左右发布。但是，我们将尽快提供具有此改进的 BETA 版本。

于 2021-04-04T10:20:47.217 回答
0

其实max-waiting-for-lock-minutes还有别的意思。我将尝试解释它：

如果为另一个进程获取锁 300 秒，则等待锁的 mongock 将只等待这 300 秒（加上半秒作为保证金）。如果max-waiting-for-lock-minutes更大，它不会使用它，因为它知道它会更早发布，所以它被忽略了。

但是，如果max-waiting-for-lock-minutes较小，则会引发异常，因为 Mongock 知道您不希望该服务等待那么长时间来尝试。

所以建议的配置总是max-waiting-for-lock-minutes略大于Lock-acquired-for-minutes，允许的最小值是 2 分钟。

于 2021-03-31T22:29:50.047 回答