1.2 Challenges on Windows 10

Following the video steps AFAIK I have:

  1. created the key file and after much searching finally dealt with the Windows issue of
    permissions when the file is created in the ~share folder
  2. shutdown each replica set
  3. created ‘db’ folders

Next, for each of the 3 replicate set member I run (r0, r1, and r2) of the form


mongod --replSet TO_BE_SECURED --dbpath ~/M310-HW-1.2/r1/db --logpath ~/M310-HW-1.2/r1/mongod.log --port 31121 --fork --keyFile ~/mongodb-keyfile

about to fork child process, waiting until server is ready for connections.
forked process: 13084
child process started successfully, parent exiting

I then run mongo shell
Use the admin database
I create the admin user per instructions
I then authenticate as admin

rs.add(“database:31120”);
{
“ok” : 0,
“errmsg” : “Quorum check failed because not enough voting nodes responded; required 2 but only the following 1 voting nodes responded: database:27017; the following nodes did not respond affirmatively: database:31120 failed with not authorized on admin to execute command { replSetHeartbeat: “TO_BE_SECURED”, pv: 1, v: 2, from: “database:27017”, fromId: 0, checkEmpty: false }”,
“code” : 74
}

However, I see in the r0 log file

2018-11-20T04:55:53.834+0000 I ACCESS [conn4] Unauthorized: not authorized on admin to execute command { replSetHeartb
eat: “TO_BE_SECURED”, pv: 1, v: 2, from: “database:27017”, fromId: 0, checkEmpty: false }

Next I run rs.status()

ongoDB Enterprise TO_BE_SECURED:PRIMARY> rs.status()
{
“set” : “TO_BE_SECURED”,
“date” : ISODate(“2018-11-20T05:14:57.827Z”),
“myState” : 1,
“term” : NumberLong(1),
“heartbeatIntervalMillis” : NumberLong(2000),
“members” : [
{
“_id” : 0,
“name” : “database:27017”,
“health” : 1,
“state” : 1,
“stateStr” : “PRIMARY”,
“uptime” : 3844,
“optime” : {
“ts” : Timestamp(1542687218, 1),
“t” : NumberLong(1)
},
“optimeDate” : ISODate(“2018-11-20T04:13:38Z”),
“electionTime” : Timestamp(1542687073, 2),
“electionDate” : ISODate(“2018-11-20T04:11:13Z”),
“configVersion” : 1,
“self” : true
}
],
“ok” : 1
}

Could you please check the following:

  1. That all three processes are up and running.
  2. That the keyfile being used for all members is the same. You can do this by running a diff or a checksum on each of the keyfiles.

Hi Bill_89515,

I’m not sure I understand your step:

  1. created ‘db’ folders.

When you run the setup script it creates the data directories. What we want to do in this lesson is enable authentication on an existing replica set that does not have authentication enabled. So imagine in a production environment with existing populated databases - you wouldn’t want to create new empty data directories in order to enable authentication.

The “Quorum check failed because not enough voting nodes…” error message usually indicates the nodes can’t communicate - this could be as barryoneill is asking - that there are different keyfiles.

In this lesson you just need to shut the servers - and restart them with the authentication options. ( no need to create directories, initialize or reconfigure the replica set ).

  • Safely shutdown each member of the replica set, starting with the secondaries to prevent any rollbacks.

  • Starting with the primary, restart each member using the shared keyfile you generated.

Hope that helps,

David

1 Like

Hi David, Thank you for the reply.
For the lab I was following my hand written notes and Kirby’s video steps.
I must have gone astray somewhere. I thought it was odd that I created those directories.
There may be some artifacts from my interactions so I’ll probably re-grab
the VM images and start fresh.

I suggest adding a note in the courseware itself stating Windows users not to create the key file in the ‘shared’ folder. That messes up permissions and results in start up errors. I eventually found this info when searching the discussion posts.

Happy Thanksgiving

1 Like

Hi Bill,

If you ever need to start over for this lab and subsequent labs - I would shut down any mongod servers running and delete the corresponding data directories - and you’re back to the start.

Shouldn’t be any need to re-grab the VM images or re provision the VMs.

For example for this assignment delete directory M310-HW-1.2 and all it’s sub directories and files.

Happy Thanksgiving

David

Thank you for the info. I was able to run through the homework properly.
I have one question.
I started the mongod instances with a modified for the homework version of the set up script.
I ran the mongo shell on the first mongod’s port. I then used the admin world via
MongoDB Enterprise TO_BE_SECURED:SECONDARY> use admin

The result was
switched to db admin
MongoDB Enterprise TO_BE_SECURED:SECONDARY>

I was expecting to see “:PRIMARY>” in the prompt at this point though.
What circumstances would lead to the 2nd mongod being the ‘primary’ in my case?

Hi Bill_89515,

I would recommend M103: Basic Cluster Administration to get a better understanding of replica sets.

In the case of the script when rs.initiate() gets executed the replica set gets configured and an election occurs to select the primary. With the basics/default replica set configuration being deployed in this script the node elected as Primary is random. There are setting/configuration options that can affect which node gets elected primary but those are not being used in this script.

https://docs.mongodb.com/manual/replication/

Hope this helps,

David

1 Like

Like @dschupp, I can only recommend M103 (and maybe M001 also explains some of it). Basically, in order for another node to become the primary, the current primary either A) needs to step down, or B) become unavailable. Then the secondary will still only become primary if a majority of nodes is available to vote.

Thank you for the M103 recommendations and primary election behavior. I’ll certainly sign up for the course the next time it is available. It sounds like it will fill in key gaps.

1 Like