MongoDB Balancer超时，延迟复制品

Question

我们设置了两个MongoDB碎片。每个碎片都包含一个主人，一个奴隶，一个24小时的奴隶延迟奴隶和一个仲裁者。但是，平衡器未能迁移任何等待延迟奴隶迁移的碎片。我尝试在Balancer配置中将_ secondartthrottle设置为false，但我仍然有问题。

看来迁移持续了一天，然后失败（在日志中等待奴隶消息）。最终它放弃并开始新的迁移。消息说等待3个奴隶，但是延迟从属被隐藏和prio 0，因此应该等待那个奴隶。而且，如果_scondarthrottle起作用，则不应等待任何从属吗？

现在已经有几个月了，因此应该在所有杂种上重新加载配置。一些运行平衡器的杂种最近是RISTARTER。

有人知道如何解决问题吗？在开始延迟的奴隶之前，我们没有这些问题，但这只是我们的理论。

配置：

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

来自shard1主过程的日志：

迁移]警告：迁移提交等待3个奴隶'xxx.xxx'{shardkey：objectid（'4fd2025ae087c37d32039a9e'）}} - > {shardkey> {shardkey：objectid：objectid：objectid（'4fd2035ae forefor（'4fd2035ae for for for for for for for for for for复制要在进入关键部分之前赶上

来自shard2主过程的日志：

星期二12月3日14：52：25.302 [CONN1369472] MOVECHUNK数据传输进度：{Active：trim，ns：“ xxx.xxx”，来自： '4FD2025AE087C37D32039AE'）}，最大：{shardkey：objectid（'4fd2035ae087c37f04014a79'）}，shardkeypattern：{shardkey：{shardkey：1.0}，状态：1.0}，状态： 0}，确定：1.0}我的MEM使用：0

更新：我确认删除Slavedelay让平衡器再次工作。一旦他们开始加速，大块就移动了。因此，问题似乎与斯拉夫德莱有关。我还确认平衡器以“次级throthottle”：false运行。无论如何，它似乎确实在等待奴隶。

shard2：

星期二12月10日11：44：25.423 [迁移]警告：迁移提交等待3个奴隶'xxx.xxx'{shardkey：objectid（'4ff1213ee087c3516b2f703f703f'} 52A6F089：81

星期二12月10日11：44：26.423 [migrateThread]等待复制在输入关键部分之前赶上

星期二12月10日11：44：27.423 [migrateThread]等待复制在输入关键部分之前赶上

星期二12月10日11：44：28.423 [migrateThread]等待复制在输入关键部分之前赶上

星期二12月10日11：44：29.424 [migrateThread]等待复制在输入关键部分之前赶上

星期二12月10日11：44：30.424 [migrateThread]等待复制在输入关键部分之前赶上

星期二12月10日11：44：31.424 [migrateThread]等待复制在输入关键部分之前赶上

星期二12月10日11：44：31.424 [migrateThread]迁移委员会成功地冲洗到'xxx.xxx'{shardkey：objectid（'4ff1213ee087c3516b2f703f703f''）

星期二12月10日11：44：31.425 [migrateThread]迁移提交被冲洗到日记中的日记，用于'xxx.xxx'{shardkey：objectid（'4FF1213EE087C3516B2F703F'}

星期二12月10日11：44：31.647 [migrateThread]迁移委员会成功地冲洗到'xxx.xxx'{shardkey：objectid（'4ff1213ee087c3516b2f703f703f'）

星期二12月10日11：44：31.667 [migrateThread]迁移提交被冲入日记中的日记，用于'xxx.xxx'{shardkey：objectid（'4FF1213EE087C3516B2F703F'}

Answer 1

平衡器正常等待目的地碎片的大部分副本集，以便在启动源shard上删除这些文档的删除之前将文档迁移。

问题在于，您的副本集中有四个成员（主人，一个从属，一个24小时的奴隶延迟奴隶和一个仲裁者）。这意味着三是多数。我不确定为什么要添加仲裁者，但是如果您将其删除，那么两个将是多数，而平衡器将不必等待延迟的从属。

实现相同结果的替代方法是用 votes:0 财产并离开仲裁者作为第三个投票节点。

Answer 2

您正在运行什么版本？在2.4.2及以下以及2.2.4及以下有一个已知的错误，导致集合中次要数量的计数不正确（因此，无法满足默认值 W：多数 写迁移）。这是错误（固定在2.4.3+和2.2.5+中）：

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

关闭次要油门应该是有效的解决方法，但您可能想做一个 flushrouterconfig 任何 mongos 流程（或仅重新启动所有 mongos 流程）以确保设置为您的迁移生效，尤其是如果它们需要一天时间。作为升级之前的另一个潜在解决方案，您也可以 放下本地。 （将重新创建）。