Dmi*_*try 5 mongodb mongodb-replica-set
设置:具有 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"
}
Run Code Online (Sandbox Code Playgroud)
但是,在并行终端中运行的 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
Run Code Online (Sandbox Code Playgroud)
难道我做错了什么?
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
...
Run Code Online (Sandbox Code Playgroud)
基本上,长时间运行的用户操作似乎是由于一旦尝试切换并一直增长直到失败而变得非零的结果。然后一切恢复正常。rs.stepDown()secs_runningPRIMARYstepDown
关于为什么会发生这种情况以及这是否正常有什么想法吗?
小智 0
在降级之前,rs.stepDown() 将尝试终止长时间运行的用户操作,这些操作将阻止主服务器降级,例如索引构建、写入操作或映射缩减作业。
您有一些长期的工作要做吗?检查数据库。检查结果db.currentOp()
您可以尝试设置更长的降压时间rs.stepDown(60, 360)。
| 归档时间: |
|
| 查看次数: |
10151 次 |
| 最近记录: |