wiredTiger cache size issue with "Lab - Configure a Sharded Cluster"

MongoDB University M103: Basic Cluster Administration
#1

I think a lot of people are having issues with this, according to the discussion forum. I am unable to validate this first lab. In desperation I created a new VM and created a fresh m103-repl set, then the config cluster, mongos, etc but still getting errors when I validate the loab.

$ validate_lab_first_sharded_cluster
Replica set ‘m103-repl’ not configured correctly - make sure each node is started with
a wiredTiger cache size of 0.1 GB. Your cluster will crash in the following lab
if you don’t do this!

I have double checked and the servers in the cluster ‘m103-repl’ are running with the memory restriction
$ grep cacheSizeGB mongod-repl-*.conf
mongod-repl-1.conf: cacheSizeGB: .1
mongod-repl-2.conf: cacheSizeGB: .1
mongod-repl-3.conf: cacheSizeGB: .1

I have also checked the 3 nodes using db.serverStatus().wiredTiger.cache
In each case it returns this value along with many other configurataions:-
“maximum bytes configured” : 106954752.
It equates to approximately 0.1GB.

Any help greatly appreciated.

Garrett

#2

Hello,

So you have your data replica set runing, your config server replica set running and your mongos running, and then you have run your validation routine.

And your storage area of your config looks like this?

storage:
dbPath: /var/mongodb/db/1
wiredTiger:
engineConfig:
cacheSizeGB: .1

#3

Hi NMullins,

thanks for taking a look. Yes, have modified all 3 config files like this

sharding:
  clusterRole: shardsvr
storage:
  dbPath: /var/mongodb/db/1
  wiredTiger:
    engineConfig:
      cacheSizeGB: .1

And as I understand it, db.serverStatus().wiredTiger.cache is confirming that I have set this correctly.
This is what the MONGOS server looks like. - looks good to me!
MongoDB Enterprise mongos> sh.status()
— Sharding Status —
sharding version: {
“_id” : 1,
“minCompatibleVersion” : 5,
“currentVersion” : 6,
“clusterId” : ObjectId(“5c4b28c38d131db5d7e912cf”)
}
shards:
{ “_id” : “m103-repl”, “host” : “m103-repl/192.168.103.100:27001,192.168.103.100:27002,m103:27003”, “state” : 1 }
active mongoses:
“3.6.10” : 1
autosplit:
Currently enabled: yes
balancer:
Currently enabled: yes
Currently running: no
Failed balancer rounds in last 5 attempts: 0
Migration Results for the last 24 hours:
No recent migrations
databases:
{ “_id” : “applicationData”, “primary” : “m103-repl”, “partitioned” : false }
{ “_id” : “config”, “primary” : “config”, “partitioned” : true }
config.system.sessions
shard key: { “_id” : 1 }
unique: false
balancing: true
chunks:
m103-repl 1
{ “_id” : { “$minKey” : 1 } } -->> { “_id” : { “$maxKey” : 1 } } on : m103-repl Timestamp(1, 0)
Garrett

#4

Hey Garrett,

In your shard listing, the ‘IP’ for the the third node in the shard is ‘m103:27003’.
So yours looks like this:
{ “_id” : “m103-repl”, “host” : “m103-repl/192.168.103.100:27001,192.168.103.100:27002,m103:27003”, “state” : 1 }

And mine looks like this:
{ “_id” : “m103-repl”, “host” : “m103-repl/192.168.103.100:27001,192.168.103.100:27002,192.168.103.100:27003”, “state” : 1 }

I ran into problems with the ‘m103’ hostname in an earlier lab, so I backed it out. I wonder if it’s causing an issue. Theoretically it shouldn’t, but I also found an earlier lab wouldn’t validate because I had 4 nodes up instead of 3…

I just tried to duplicate the issue by updating my config files for node3 to use ‘m103’ as the hostname, tried restarting it and the mongos but the status won’t update in sh.status().
Sorry I can’t prove it right now.

#5

I would definitely recommend swapping over the 3rd node, back to an ip address.

I noticed that if I left in the m103:27003, that the replica set wouldn’t communicate properly, since it couldn’t resolve m103 to an ip address that it needed.

#6

I ran
rs.remove(“m103:27003”)
rs.add(“192.168.103.100:27003”)

The mongoS is now using the IP addresses.
shards:
{ “_id” : “m103-repl”, “host” : “m103-repl/192.168.103.100:27001,192.168.103.100:27002,192.168.103.100:27003”, “state” : 1 }
Unfortunately, I still cannot validate it as it continued to whine about the wireTiger cache size

#7

Did you find the solution? I am also getting the same message from validation.

#8

Try adding below to hosts(/etc/hosts) file of your VM

192.168.103.100 m103 m103.mongodb.university

#9

Thanks artemly. Just did that and re-ran the validation test but still getting the error below, so I don’t think it is a problem loging into the cluster.

$ validate_lab_first_sharded_cluster

Replica set 'm103-repl' not configured correctly - make sure each node is started with
a wiredTiger cache size of 0.1 GB. Your cluster will crash in the following lab
if you don't do this!
#10

not yet Syed. what error messages are you getting?

#11

I spent a lot of time, trying to follow step by step provided guidelines in order to complete this lab without the same wrong validation message. No luck. The bad thing is the following labs are based on this replica set configuration not passing their validations respectively in spite of the fact you can see all required status reports. I am wondering if anybody from the university staff can provide any input referencing to this issue

#12

I had lot of issues during this validation stage and getting below error
don’t use alias m103 in vagrant.It is not resolving

vagrant@m103:/var/mongodb/db$ validate_lab_first_sharded_cluster

Mongos not configured correctly - make sure you have added the replica set m103-repl as
your first shard.

I did these changes in /etc/hosts as sudo
127.0.0.1 m103.mongodb.university m103
net:
bindIp: m103,localhost—changed to IP instead and restarted mongod

#13

I got EXACTLY the same problemo! Please lemme know if you have resolve this problemo!

The lab instructions says:

" The cacheSizeGB: .1 section restricts the memory usage of each running mongod. Note that this is not good practice . However, in order to run a sharded cluster inside a virtual machine with only 2GB of memory, certain adjustments must be made."

It says adjustment, but by how much? This is not clear for me since English is my third language.

#14

For VM? How you do that? Pls.

#15

In the instructions on the configuration it says “.1” and not “0.1”… would this make a difference?
I used “.1” without double quotes, of course.

#16

Thanks bobvar. I pasted in the relevant section form the config file at the top of this discussion. I did specify .1. I also double checked for the use of TABs, as these are not allowed. I also ensured that all indentations were by 2 spaces, although I doubt this matters. I restarted every thing and the validation still does not return a result despite

  1. rs.isMaster() shows the replication set is correct
  2. sh.status() shows the replication set has been recognised

Time to give up on this lab and move onwards. I know the next lab will also fail, as they are linked. but the lab after than and a good score from the final exam should be enough to pass the course.

#17

Many thanks for the heads-up. I am not taking succeeding labs. You are right, this one is linked to the next labs.