我们设置了两个mongodb分片。每个分片包含一个主机，一个从机，一个24h从机延迟从机和一个仲裁器。 但是，平衡器无法迁移任何等待延迟从属设备迁移的分片。 我已经尝试在平衡器配置中将_secondaryThrottle设置为false，但我仍有问题。
似乎迁移持续了一天然后失败（大量等待日志中的从属消息）。最终它放弃并开始新的迁移。消息说等待3个从站，但是延迟从站被隐藏并且prio 0所以它应该等待那个。如果_SecondaryThrottle工作，它不应该等待任何奴隶吗？
现在已经好几个月了，所以应该在所有mongoses上重新加载配置。一些运行平衡器的mongoses最近已经重新启动。
有没有人知道如何解决问题，我们在启动延迟奴隶之前没有遇到这些问题，但这只是我们的理论。
配置：
{ "_id" : "balancer", "_secondaryThrottle" : false, "stopped" : false }
从shard1主进程记录：
[migrateThread]警告：migrate commit等待3个slave 'xxx.xxx'{shardkey：ObjectId（'4fd2025ae087c37d32039a9e'）} - ＆gt; {shardkey：ObjectId（'4fd2035ae087c37f04014a79'）}等待： 529dc9d9：7a [migrateThread]等待复制赶上之前 进入关键部分
从shard2主进程记录：
Tue Dec 3 14：52：25.302 [conn1369472] moveChunk数据传输 进度：{active：true，ns：“xxx.xxx”，来自： “shard2 / mongo2：27018，mongob2：27018”，min：{shardkey： ObjectId（'4fd2025ae087c37d32039a9e'）}，max：{shardkey： ObjectId（'4fd2035ae087c37f04014a79'）}，shardKeyPattern：{shardkey： 1.0}，状态：“catchup”，计数：{cloned：22773，clonedBytes：36323458，catchup：0，stable：0}，ok：1.0}我的mem使用：0
更新： 我确认删除slaveDelay让平衡器再次工作。一旦他们加快了速度块的移动。所以问题似乎与slaveDelay有关。我还确认平衡器以“secondaryThrottle”运行：false。无论如何，它确实似乎在等待奴隶。
Shard2：
Tue Dec 10 11：44：25.423 [migrateThread]警告：迁移提交等待'xxx.xxx'的3个奴隶{shardkey：ObjectId（'4ff1213ee087c3516b2f703f'）} - ＆gt; {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]在进入关键部分之前等待复制赶上
12月10日星期二11：44：31.424 [migrateThread]在进入关键部分之前等待复制赶上
Tue Dec 10 11：44：31.424 [migrateThread] migrate commit succeeded flushing to secondaries for'xxx.xxx'{shardkey：ObjectId（'4ff1213ee087c3516b2f703f'）} - ＆gt; {shardkey：ObjectId（'4ff12a5eddf2b32dff1e7bea'）}
Tue Dec 10 11：44：31.425 [migrateThread] migrate commit flushed to journal for'xxx.xxx'{shardkey：ObjectId（'4ff1213ee087c3516b2f703f'）} - ＆gt; {shardkey：ObjectId（'4ff12a5eddf2b32dff1e7bea'）}
Tue Dec 10 11：44：31.647 [migrateThread] migrate commit succeeded flushing to secondaries for'xxx.xxx'{shardkey：ObjectId（'4ff1213ee087c3516b2f703f'）} - ＆gt; {shardkey：ObjectId（'4ff12a5eddf2b32dff1e7bea'）}
Tue Dec 10 11：44：31.667 [migrateThread] migrate commit flushed to journal for'xxx.xxx'{shardkey：ObjectId（'4ff1213ee087c3516b2f703f'）} - ＆gt; {shardkey：ObjectId（'4ff12a5eddf2b32dff1e7bea'）}
答案 0 :(得分：2)
在开始删除源分片上的那些文档之前，均衡器正在等待目标分片的副本集的MAJORITY以便迁移文档。
问题是你的副本集中有四个成员（主服务器，从服务器，24小时从服务器延迟服务器和仲裁服务器）。这意味着三个占多数。我不确定你为什么添加仲裁器，但是如果你删除它，那么TWO将占多数，而平衡器将不必等待延迟的从属。
实现相同结果的另一种方法是设置具有votes:0属性的延迟从属设备，并将仲裁器保留为第三个投票节点。
答案 1 :(得分：0)
你在运行什么版本？ 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（它将被重新创建）。