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

Question

我们设置了两个mongodb分片.每个分片包含一个主机,一个从机,一个24h从机延迟从机和一个仲裁器.但是,平衡器无法迁移任何等待延迟从属设备迁移的分片.我已经尝试在balancer配置中将_secondaryThrottle设置为false,但我仍然有问题.

似乎迁移持续了一天然后失败(大量等待日志中的从属消息).最终它放弃并开始新的迁移.消息说等待3个从站,但是延迟从站被隐藏并且prio 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主进程登录:

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'{shardkey:ObjectId('4ff1213ee087c3516b2f703f')} - > {shardkey:ObjectId('4ff12a5eddf2b32dff1e7bea')}等待: 52a6f089:81

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

Tue Dec 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]在进入关键部分之前等待复制赶上

Tue Dec 10 11:44:31.424 [migrateThread] migrate commit succeeded flushing to secondaries for'xxx.xxx'{shardkey:ObjectId('4ff1213ee087c3516b2f703f')} - > {shardkey:ObjectId('4ff12a5eddf2b32dff1e7bea')}

Tue Dec 10 11:44:31.425 [migrateThread] migrate commit flushed to journal for'xxx.xxx'{shardkey:ObjectId('4ff1213ee087c3516b2f703f')} - > {shardkey:ObjectId('4ff12a5eddf2b32dff1e7bea')}

Tue Dec 10 11:44:31.647 [migrateThread] migrate commit succeeded flushing to secondaries for'xxx.xxx'{shardkey:ObjectId('4ff1213ee087c3516b2f703f')} - > {shardkey:ObjectId('4ff12a5eddf2b32dff1e7bea')}

Tue Dec 10 11:44:31.667 [migrateThread] migrate commit flushed to journal for'xxx.xxx'{shardkey:ObjectId('4ff1213ee087c3516b2f703f')} - > {shardkey:ObjectId('4ff12a5eddf2b32dff1e7bea')}

Answer 1

平衡器正在正确等待目标分片的大部分副本集迁移文档，然后再启动源分片上的这些文档的删除。

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

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