Error running validation script after creating initial replica set

I successfully created a replica set using the instructions from the “Lab - Initiate a Replica Set Locally”, but when I run the validation script I get the following error:

“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.”

I used the following command to create the user on the admin database:

db.createUser({
user: “m103-admin”,
pwd: “m103-pass”,
roles: [
{role: “root”, db: “admin”}
]
})

and when I run the “db.getUsers()” command from the primary node I get the following output:

[
{
“_id” : “admin.m103-admin”,
“user” : “m103-admin”,
“db” : “admin”,
“roles” : [
{
“role” : “root”,
“db” : “admin”
}
]
}
]

I’m able to successfully connect to the replica set with each of the following commands:

mongo --host “m103-example/192.168.103.100:27001” -u “m103-admin” -p “m103-pass” --authenticationDatabase “admin”

mongo --host “m103-example/192.168.103.100:27002” -u “m103-admin” -p “m103-pass” --authenticationDatabase “admin”

mongo --host “m103-example/192.168.103.100:27003” -u “m103-admin” -p “m103-pass” --authenticationDatabase “admin”

Which means the mongos are running on the correct ports and the m103-admin user does indeed authenticate against the admin database, so why am I getting this error instead of an authentication code?

1 Like

MongoDB Enterprise m103-example:PRIMARY> rs.status()
{
“set” : “m103-example”,
“date” : ISODate(“2019-05-25T21:44:08.871Z”),
“myState” : 1,
“term” : NumberLong(1),
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“heartbeatIntervalMillis” : NumberLong(2000),
“optimes” : {
“lastCommittedOpTime” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
},
“readConcernMajorityOpTime” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
},
“appliedOpTime” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
},
“durableOpTime” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
}
},
“members” : [
{
“_id” : 0,
“name” : “192.168.103.100:27001”,
“health” : 1,
“state” : 1,
“stateStr” : “PRIMARY”,
“uptime” : 19339,
“optime” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
},
“optimeDate” : ISODate(“2019-05-25T21:44:07Z”),
“syncingTo” : “”,
“syncSourceHost” : “”,
“syncSourceId” : -1,
“infoMessage” : “”,
“electionTime” : Timestamp(1558801491, 2),
“electionDate” : ISODate(“2019-05-25T16:24:51Z”),
“configVersion” : 3,
“self” : true,
“lastHeartbeatMessage” : “”
},
{
“_id” : 1,
“name” : “192.168.103.100:27002”,
“health” : 1,
“state” : 2,
“stateStr” : “SECONDARY”,
“uptime” : 18009,
“optime” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
},
“optimeDurable” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
},
“optimeDate” : ISODate(“2019-05-25T21:44:07Z”),
“optimeDurableDate” : ISODate(“2019-05-25T21:44:07Z”),
“lastHeartbeat” : ISODate(“2019-05-25T21:44:07.739Z”),
“lastHeartbeatRecv” : ISODate(“2019-05-25T21:44:07.738Z”),
“pingMs” : NumberLong(0),
“lastHeartbeatMessage” : “”,
“syncingTo” : “192.168.103.100:27003”,
“syncSourceHost” : “192.168.103.100:27003”,
“syncSourceId” : 2,
“infoMessage” : “”,
“configVersion” : 3
},
{
“_id” : 2,
“name” : “192.168.103.100:27003”,
“health” : 1,
“state” : 2,
“stateStr” : “SECONDARY”,
“uptime” : 17801,
“optime” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
},
“optimeDurable” : {
“ts” : Timestamp(1558820647, 1),
“t” : NumberLong(1)
},
“optimeDate” : ISODate(“2019-05-25T21:44:07Z”),
“optimeDurableDate” : ISODate(“2019-05-25T21:44:07Z”),
“lastHeartbeat” : ISODate(“2019-05-25T21:44:07.740Z”),
“lastHeartbeatRecv” : ISODate(“2019-05-25T21:44:07.738Z”),
“pingMs” : NumberLong(0),
“lastHeartbeatMessage” : “”,
“syncingTo” : “192.168.103.100:27001”,
“syncSourceHost” : “192.168.103.100:27001”,
“syncSourceId” : 0,
“infoMessage” : “”,
“configVersion” : 3
}
],
“ok” : 1,
“operationTime” : Timestamp(1558820647, 1),
“$clusterTime” : {
“clusterTime” : Timestamp(1558820647, 1),
“signature” : {
“hash” : BinData(0,“0hZwucegbvD28/UCN72NsCsehAA=”),
“keyId” : NumberLong(“6695001433390972930”)
}
}
}

Please double check your config files and lab requirements
Use the same names suggested in lab
Is your replicaset name correct and ports/dirs etc
If you deviate from what was asked in your lab validation script fails

I had the same problem.
It was a typo problem " m103-admin" instead of “m103-admin”.

In your case, it seems to be that your replica set name is “m103-example” (first line of the rs.status output) instead of “m103-repl”,
With a quick search on the doc, it seems that you can’t change the replica set name once set. So you’ll probably have to start again the lab. But as I said, I didn’t look deeply in the documentation. Maybe you can find a solution to change the name.

1 Like