具有延迟副本的 MongoDB 平衡器超时答案

【问题标题】：MongoDB balancer timeout with delayed replica具有延迟副本的 MongoDB 平衡器超时
【发布时间】：2013-12-19 15:14:09
【问题描述】：

我们设置了两个 mongodb 分片。每个 shard 包含一个 master、一个 slave、一个 24h slave delay slave 和一个 arbiter。然而，平衡器无法迁移任何等待延迟从属迁移的分片。我尝试在平衡器配置中将 _secondaryThrottle 设置为 false，但我仍然遇到问题。

迁移似乎持续了一天然后失败（大量等待日志中的从属消息）。最终它放弃并开始新的迁移。消息说正在等待 3 个从站，但是延迟从站是隐藏的并且优先级为 0，因此它应该等待那个。如果 _secondaryThrottle 工作，它不应该等待任何奴隶吗？

几个月来一直这样，所以配置应该已经在所有 mongoses 上重新加载。一些运行平衡器的 mongoses 最近已经重新启动。

有没有人知道如何解决这个问题，在启动延迟从站之前我们没有这些问题，但这只是我们的理论。

配置：

{ "_id" : "balancer", "_secondaryThrottle" : false, "stopped" : false }

来自 shard1 主进程的日志：

[migrateThread] 警告：迁移提交等待 3 个从属 'xxx.xxx' { shardkey: ObjectId('4fd2025ae087c37d32039a9e') } -> {shardkey: ObjectId('4fd2035ae087c37f04014a79') } 等待： 529dc9d9:7a [migrateThread] 等待复制赶上之前进入临界区

来自 shard2 主进程的日志：

12 月 3 日星期二 14:52:25.302 [conn1369472] moveChunk 数据传输进度：{活动：true，ns：“xxx.xxx”，来自： "shard2/mongo2:27018,mongob2:27018", min: { shardkey: ObjectId('4fd2025ae087c37d32039a9e') }，最大值：{ shardkey: ObjectId('4fd2035ae087c37f04014a79') }, shardKeyPattern: { shardkey: 1.0 }, state: "catchup", counts: { cloned: 22773, clonedBytes: 36323458, catchup: 0, stable: 0 }, ok: 1.0 } my mem used: 0

更新：我确认删除 slaveDelay 使平衡器再次工作。一旦他们加快速度，大块就移动了。所以问题似乎与slaveDelay有关。我还确认平衡器以“secondaryThrottle”运行：false。无论如何，它似乎确实在等待奴隶。

分片2：

12 月 10 日星期二 11:44:25.423 [migrateThread] 警告：迁移提交等待 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }等待：52a6f089:81

Tue Dec 10 11:44:26.423 [migrateThread] 在进入临界区之前等待复制赶上

Tue Dec 10 11:44:27.423 [migrateThread] 在进入临界区之前等待复制赶上

Tue Dec 10 11:44:28.423 [migrateThread] 在进入临界区之前等待复制赶上

Tue Dec 10 11:44:29.424 [migrateThread] 在进入临界区之前等待复制赶上

Tue Dec 10 11:44:30.424 [migrateThread] 在进入临界区之前等待复制赶上

Tue Dec 10 11:44:31.424 [migrateThread] 在进入临界区之前等待复制赶上

12 月 10 日星期二 11:44:31.424 [migrateThread] 迁移提交成功刷新到“xxx.xxx”的辅助节点 { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }

12 月 10 日星期二 11:44:31.425 [migrateThread] 迁移提交刷新到日志以获取 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }

12 月 10 日星期二 11:44:31.647 [migrateThread] migrate 提交成功刷新到 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }

12 月 10 日星期二 11:44:31.667 [migrateThread] 迁移提交刷新到日志，用于 'xxx.xxx' { shardkey: ObjectId('4ff1213ee087c3516b2f703f') } -> { shardkey: ObjectId('4ff12a5eddf2b32dff1e7bea') }

【问题讨论】：

标签： mongodb database-replication

【解决方案1】：

你运行的是什么版本？在 2.4.2 及更低版本以及 2.2.4 及更低版本中存在一个已知错误，导致集合中辅助节点数量的计数不正确（因此无法满足默认的 w:majority 迁移写入）。这是错误（在 2.4.3+ 和 2.2.5+ 中修复）：

https://jira.mongodb.org/browse/SERVER-8420

关闭辅助节流阀应该是一种有效的解决方法，但您可能需要对任何 mongos 进程执行 flushRouterConfig（或仅重新启动所有 mongos 进程）以确保设置在以下时间生效你的迁移，特别是如果他们需要一天的时间。作为升级前的另一个潜在修复，您还可以drop the local.slaves collection（它将被重新创建）。

【讨论】：

我们正在运行 2.4.6。我已经完成了 flushRouterConfig，但我不知道如何验证 mongos 进程是否具有新配置。我会阅读 local.slaves。感谢您的回答
我确认 local.slaves 集合已经过时，我现在重建它并看到它有帮助。
删除 local.slaves 没有帮助。我确认删除 slaveDelay 使平衡器再次工作。一旦他们加快速度，大块就移动了。所以问题似乎与slaveDelay有关。我还确认平衡器以“secondaryThrottle”运行：false。
我刚刚重新阅读了您的配置列表 - 您说您有一个主服务器、从服务器、延迟从服务器和一个仲裁器。那是 4 个节点，这使得多数为 3。由于您有一个没有数据的仲裁器，因此它不能满足多数写入问题。因此，要使多数写入占 3/4，您必须让所有数据承载节点都确认写入。如果你摆脱了仲裁者，你将需要 2/3，只要你有非延迟奴隶就可以满足
在确保配置已被拾取方面，我建议重新启动所有 mongos 进程，并降低所有主进程以绝对确定。关闭节流阀后，大多数写入关注点就不再需要了，因此应该删除该要求。

【解决方案2】：

平衡器正在正确地等待目标分片的副本集的 MAJORITY 迁移文档，然后再开始删除源分片上的这些文档。

问题是您的副本集中有四个成员（主服务器、从服务器、24 小时延迟从服务器和仲裁器）。这意味着三个是大多数。我不确定你为什么要添加一个仲裁器，但如果你删除它，那么两个将是多数，平衡器将不必等待延迟的从站。

实现相同结果的另一种方法是使用votes:0 属性设置延迟从站，并将仲裁器作为第三个投票节点。

【讨论】：