Question

设置：具有5个节点的副本集，版本3.4.5。

尝试使用rs.stepDown（60,30）切换PRIMARY，但一直收到错误：

rs0:PRIMARY> rs.stepDown(60, 30)
{
    "ok" : 0,
    "errmsg" : "No electable secondaries caught up as of 2017-07-11T00:21:11.205+0000. Please use {force: true} to force node to step down.",
    "code" : 50,
    "codeName" : "ExceededTimeLimit"
}

然而，在并行终端中运行的rs.printSlaveReplicationInfo（）确认所有副本都已完全赶上：

rs0:PRIMARY> rs.printSlaveReplicationInfo()
source: X.X.X.X:27017
    syncedTo: Tue Jul 11 2017 00:21:11 GMT+0000 (UTC)
    0 secs (0 hrs) behind the primary
source: X.X.X.X:27017
    syncedTo: Tue Jul 11 2017 00:21:11 GMT+0000 (UTC)
    0 secs (0 hrs) behind the primary
source: X.X.X.X:27017
    syncedTo: Tue Jul 11 2017 00:21:11 GMT+0000 (UTC)
    0 secs (0 hrs) behind the primary
source: X.X.X.X:27017
    syncedTo: Tue Jul 11 2017 00:21:11 GMT+0000 (UTC)
    0 secs (0 hrs) behind the primary

我做错了吗？

UPD：我已经在rs.stepDown之前和期间检查了长时间运行的操作，如下所示，它看起来像这样：

# Before rs.stepDown
$ watch "mongo --quiet --eval 'JSON.stringify(db.currentOp())' | jq -r '.inprog[] | \"\(.secs_running) \(.desc) \(.op)\"' | sort -rnk1"
984287 rsSync none
984287 ReplBatcher none
67 WT RecordStoreThread: local.oplog.rs none
null SyncSourceFeedback none
null NoopWriter none
0 conn615153 command
0 conn614948 update
0 conn614748 getmore
...

# During rs.stepDown
984329 rsSync none
984329 ReplBatcher none
108 WT RecordStoreThread: local.oplog.rs none
16 conn615138 command
16 conn615136 command
16 conn615085 update
16 conn615079 insert
...

基本上，长时间运行的用户操作似乎发生了 rs.stepDown()的结果，因为secs_running PRIMARY在stepDown尝试切换并且不断增长时变为非零直到{{1}}失败的方式。然后一切恢复正常。

关于为什么会发生这种情况以及这种情况是否正常的任何想法？

Answer 1

我已使用以下命令降级为中学

db.adminCommand( { replSetStepDown: 120, secondaryCatchUpPeriodSecs: 15, force: true } )

您可以在以下mongodb官方文档中找到它

https://docs.mongodb.com/manual/reference/command/replSetStepDown/

Answer 2

要关闭此问题的循环，确定失败的降级是由于主机上的时间倒退。

MongoDB 3.4.6对主机上的时间问题更具弹性，升级部署可以解决拖延问题。

Answer 3

在下台之前，rs.stepDown（）将尝试终止长时间运行的用户操作，这些操作会阻止主服务器降级，例如索引构建，写入操作或map-reduce作业。

你还有一些长期工作吗？检查db。检查db.currentOp()

的结果

您可以尝试设置更长的踩踏时间rs.stepDown(60, 360)。

Answer 4

引用https://jira.mongodb.org/browse/SERVER-27015的答案：

这很可能是由于以下事实：默认情况下，只有在执行关闭命令的确切时间完全捕获了辅助服务器时，关闭命令才会在主要服务器上成功执行。

我遇到了类似的问题，并多次尝试过db.shutdownServer()命令，但是当次要对象比主要对象落后0秒时，它确实起作用。

MongoDB主要stepDown不成功

4 个答案: