Quorum check failed because not enough voting nodes responded

MongoDB University M103: Basic Cluster Administration
#1

I have checked different answers in the forum, but I don’t find the solution.

I run:

MongoDB Enterprise m103-rpl:PRIMARY> rs.add("192.168.103.100:27002")

And the answer is:
{
“ok” : 0,
“errmsg” : “Quorum check failed because not enough voting nodes responded; required 2 but only
the following 1 voting nodes responded: 192.168.103.100:27001; the following nodes did not
respond affirmatively: 192.168.103.100:27002 failed with not authorized on admin to execute
command { replSetHeartbeat: “m103-rpl”, configVersion: 2, hbv: 1, from:
“192.168.103.100:27001”, fromId: 0, term: 1, $replData: 1, $clusterTime: { clusterTime:
Timestamp(1586276669, 1), signature: { hash: BinData(0,
F7C3396626B58FAA587E15E7319EB4CF6C3EDF85), keyId: 6812996704841760769 } }, $db:
“admin” }”,
“code” : 74,
“codeName” : “NodeNotFound”,
“operationTime” : Timestamp(1586276669, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1586276669, 1),
“signature” : {
“hash” : BinData(0,“AAAAAAAAAAAAAAAAAAAAAAAAAAA=”),
“keyId” : NumberLong(0)
}
}
}

And the other servers are running. Because I can connect the mongo shell with:

mongo --host 192.168.103.100:27002
#2

Please go through this post.

#3

Please notice above line carefully and this one too

command { replSetHeartbeat: “m103-rpl”,

#4

Finally I wiped the data file directories and it works now.
However, the result of validate_lab_initialize_local_replica_set is:

Client experienced a timeout when connecting to the database - check that mongod
processes are running on ports 27001, 27002 and 27003, and that the ‘m103-admin’
user authenticates against the admin database.

Can you help me?

The ouput of rs.status() is:

{
“set” : “m103-rpl”,
“date” : ISODate(“2020-04-08T07:54:38.248Z”),
“myState” : 1,
“term” : NumberLong(1),
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“heartbeatIntervalMillis” : NumberLong(2000),
“optimes” : {
“lastCommittedOpTime” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
},
“readConcernMajorityOpTime” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
},
“appliedOpTime” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
},
“durableOpTime” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
}
},
“members” : [
{
“_id” : 0,
“name” : “192.168.103.100:27001”,
“health” : 1,
“state” : 1,
“stateStr” : “PRIMARY”,
“uptime” : 899,
“optime” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
},
“optimeDate” : ISODate(“2020-04-08T07:54:29Z”),
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“infoMessage” : “”,
“electionTime” : Timestamp(1586331888, 2),
“electionDate” : ISODate(“2020-04-08T07:44:48Z”),
“configVersion” : 3,
“self” : true,
“lastHeartbeatMessage” : “”
},
{
“_id” : 1,
“name” : “192.168.103.100:27002”,
“health” : 1,
“state” : 2,
“stateStr” : “SECONDARY”,
“uptime” : 114,
“optime” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
},
“optimeDurable” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
},
“optimeDate” : ISODate(“2020-04-08T07:54:29Z”),
“optimeDurableDate” : ISODate(“2020-04-08T07:54:29Z”),
“lastHeartbeat” : ISODate(“2020-04-08T07:54:36.473Z”),
“lastHeartbeatRecv” : ISODate(“2020-04-08T07:54:36.946Z”),
“pingMs” : NumberLong(0),
“lastHeartbeatMessage” : “”,
“syncingTo” : “192.168.103.100:27001”,
“syncSourceHost” : “192.168.103.100:27001”,
“syncSourceId” : 0,
“infoMessage” : “”,
“configVersion” : 3
},
{
“_id” : 2,
“name” : “192.168.103.100:27003”,
“health” : 1,
“state” : 2,
“stateStr” : “SECONDARY”,
“uptime” : 106,
“optime” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
},
“optimeDurable” : {
“ts” : Timestamp(1586332469, 1),
“t” : NumberLong(1)
},
“optimeDate” : ISODate(“2020-04-08T07:54:29Z”),
“optimeDurableDate” : ISODate(“2020-04-08T07:54:29Z”),
“lastHeartbeat” : ISODate(“2020-04-08T07:54:36.474Z”),
“lastHeartbeatRecv” : ISODate(“2020-04-08T07:54:36.949Z”),
“pingMs” : NumberLong(0),
“lastHeartbeatMessage” : “”,
“syncingTo” : “192.168.103.100:27002”,
“syncSourceHost” : “192.168.103.100:27002”,
“syncSourceId” : 1,
“infoMessage” : “”,
“configVersion” : 3
}
],
“ok” : 1,
“operationTime” : Timestamp(1586332469, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1586332469, 1),
“signature” : {
“hash” : BinData(0,“i1fA/iPdHfpsjcgcYMCSdh8aG5g=”),
“keyId” : NumberLong(“6813243583856902145”)
}
}
}

The output of db.get.Users() is:

[
{
“_id” : “admin.m103-admin”,
“userId” : UUID(“b71b337e-a55e-45e6-bc95-f80d971bb263”),
“user” : “m103-admin”,
“db” : “admin”,
“roles” : [
{
“role” : “root”,
“db” : “admin”
}
]
}
]

#5

I suggest you to go through 007_jb’s post

Are you able to login to replicaset with newly created user authenticating against admin db?
Is your replicaset name correct?
Please stick to your lab requirements else validation script will fail

#7

Dear Ramachandra,
I read the 007_jb post. I wiped all the data directories and the replica set is working now. The output of the rs.status() seems ok. And I am able to connect to replicaset with:

mongo --host 192.168.103.100:27001 -u m103-admin -p m103-pass --authenticationDatabase=admin

#8

What about this?

#9

image
image938×519 25.5 KB

1 Like
#10

Thanks. I am embarrassed. I should have noticed that the name of the replica set was wrong

#11

Hello, this post is marked as private. are you able to help members get into this post? thank you.

#13

For some reason it’s now a broken link. Probably as a result of a data migration by the MongoDB team.

Here’s the fixed link. See my last post in that link.