Mongodb does not choose primary node after command rs.stepDown()?

Hi All,

I run command rs.stepDown() then I get response :

2019-12-29T05:46:11.019+0700 I CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to m103.mongodb.university:27013
2019-12-29T05:46:13.019+0700 I CONNPOOL [ReplicaSetMonitor-TaskExecutor] Connecting to m103.mongodb.university:27012

I only get the response repeteadly and mongodb does not choose PRIMARY.

What should I do ?
Normally how long does mongodb take time to choose primary node ?

Thanks in advance.

Which node did you run this on? And let’s see the command you are using to connect to your replica set.

hi,

thank you for your respond.
I run the command on node 1.

What about… :arrow_up: :question:

I close the terminal then I open new terminal.

I run command :
mongo --host “m103-example/m103.mongodb.university:27011” -u m103-admin -p m103-pass --authenticationDatabase admin

in mongo shell I type rs.status(). The response is :

MongoDB Enterprise m103-example:PRIMARY> rs.status()
{
“set” : “m103-example”,
“date” : ISODate(“2019-12-28T23:01:33.444Z”),
“myState” : 1,
“term” : NumberLong(2),
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“heartbeatIntervalMillis” : NumberLong(2000),
“optimes” : {
“lastCommittedOpTime” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
},
“readConcernMajorityOpTime” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
},
“appliedOpTime” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
},
“durableOpTime” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
}
},
“members” : [
{
“_id” : 0,
“name” : “192.168.103.100:27011”,
“health” : 1,
“state” : 2,
“stateStr” : “SECONDARY”,
“uptime” : 123,
“optime” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
},
“optimeDurable” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
},
“optimeDate” : ISODate(“2019-12-28T23:01:25Z”),
“optimeDurableDate” : ISODate(“2019-12-28T23:01:25Z”),
“lastHeartbeat” : ISODate(“2019-12-28T23:01:31.977Z”),
“lastHeartbeatRecv” : ISODate(“2019-12-28T23:01:33.017Z”),
“pingMs” : NumberLong(0),
“lastHeartbeatMessage” : “”,
“syncingTo” : “m103.mongodb.university:27013”,
“syncSourceHost” : “m103.mongodb.university:27013”,
“syncSourceId” : 2,
“infoMessage” : “”,
“configVersion” : 5
},
{
“_id” : 1,
“name” : “m103.mongodb.university:27012”,
“health” : 1,
“state” : 1,
“stateStr” : “PRIMARY”,
“uptime” : 39228,
“optime” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
},
“optimeDate” : ISODate(“2019-12-28T23:01:25Z”),
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“infoMessage” : “”,
“electionTime” : Timestamp(1577572479, 1),
“electionDate” : ISODate(“2019-12-28T22:34:39Z”),
“configVersion” : 5,
“self” : true,
“lastHeartbeatMessage” : “”
},
{
“_id” : 2,
“name” : “m103.mongodb.university:27013”,
“health” : 1,
“state” : 2,
“stateStr” : “SECONDARY”,
“uptime” : 2704,
“optime” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
},
“optimeDurable” : {
“ts” : Timestamp(1577574085, 1),
“t” : NumberLong(2)
},
“optimeDate” : ISODate(“2019-12-28T23:01:25Z”),
“optimeDurableDate” : ISODate(“2019-12-28T23:01:25Z”),
“lastHeartbeat” : ISODate(“2019-12-28T23:01:31.806Z”),
“lastHeartbeatRecv” : ISODate(“2019-12-28T23:01:32.596Z”),
“pingMs” : NumberLong(0),
“lastHeartbeatMessage” : “”,
“syncingTo” : “m103.mongodb.university:27012”,
“syncSourceHost” : “m103.mongodb.university:27012”,
“syncSourceId” : 1,
“infoMessage” : “”,
“configVersion” : 5
}
],
“ok” : 1,
“operationTime” : Timestamp(1577574085, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1577574085, 1),
“signature” : {
“hash” : BinData(0,“v/vQ59UJpTatB7sdHoD+rjGCqI0=”),
“keyId” : NumberLong(“6775462191073067009”)
}
}
}

node “192.168.103.100:27011” becomes SECONDARY
node “m103.mongodb.university:27012” becomes PRIMARY
node “m103.mongodb.university:27013” is still SECONDARY

So there’s no problem anymore right?

Fyi, for next time, it’s good practice to include all three hostnames in your connection string:
mongo --host “m103-example/m103.mongodb.university:27011,m103.mongodb.university:27012,m103.mongodb.university:27013” -u m103-admin -p m103-pass --authenticationDatabase admin

Also, you don’t need to close the terminal next time. Just Ctrl+C or Ctrl+D to come out of the mongo shell, and you can reconnect again using the same terminal.

1 Like

yes.

my problem is solved. Thank you.

:slightly_smiling_face: :+1:

Closing the thread as the issue has been resolved.