POCDriver connection string format

Can anyone help me assemble the correct connection string for POCDriver please?

During the lesson on insert performance I was trying to follow along with my own Atlas cluster (created during M001, with one primary and two secondaries), but I’ve been unable to work out the format of the connection string. The closest I’ve got is this

java -jar POCDriver.jar -c "mongodb+srv://<username>:<password>@cluster0-<my cluster's random string>.gcp.mongodb.net/test"

But this gives me an error

Exception in thread "main" com.mongodb.MongoCommandException: Command failed with error 8000 (AtlasError): 'user is not allowed to do action [serverStatus] on [admin.]' on server cluster0-shard-00-00-<my cluster's random string>.gcp.mongodb.net:27017. The full response is { "ok" : 0, "errmsg" : "user is not allowed to do action [serverStatus] on [admin.]", "code" : 8000, "codeName" : "AtlasError" }

I’m pretty sure it’s not an authentication failure as I can connect using the Mongo shell with the same credentials.

I’ve got a horrible feeling that this is something to do with how the shards / nodes (what’s the correct term here?) in the cluster are referenced and how the cluster itself is referenced, and that I should have done the M103 administration course to get a proper understanding of that subject before attempting this course. But I am where I am, and any pointers would be gratefully received.

If I omit the -c argument entirely then I can successfully run POCDriver against my local Mongo instance, although the lesson video specifically mentions that the Atlas cluster is a “3 member replica set” whereas I believe my local instance has only one shard / node / whatever the term is (Compass describes it as “standalone”). Is it significant that the cluster used in the lesson consists of 3 members or is it just as valid for the purposes of this lesson to use my local instance?

In any case, I’d still like to know how to build the connection string for somewhere that’s not my local machine.

Thank you for reading this far, and please accept my apologies for doing the courses in the wrong order.

The error clearly says user lacks privileges on admin DB
I am not sure what your java script does but additional privs/roles to the user may help

“While Creating the Sandbox Cluster, make sure you have set “Read and Write to any Database” user privilege.”

Thanks, but I believe I’ve already done that? This is what Atlas tells me on the Security screen:

image

Sorry, I wasn’t clear about what that POCDriver.jar is. It’s not something I’ve written, it’s a 3rd party performance benchmarking tool from https://github.com/johnlpage/POCDriver which is used in the lecture on insert performance in chapter 4 of M201.

Here’s my screenshot from the video of the command line used to run POCDriver:

image

It seems to include multiple DNS names (if indeed that’s what they are), so I’m wondering whether some of them point to the cluster and some of them point to shards / nodes / whatever within the cluster?

@Simon_39939

Perhaps you should start by reading the documentation on connection strings for replica sets here which will give you some clarity on both nomenclature and on what the various components of the string are doing. Then go back and review both the string used in the lecture and your string and I think you’ll see some issues that may resolve your problems.

Also, FWIW, it’s just as good to use your localhost instance for this example; there’s nothing here that requires a replica set – it’s just that Atlas always does a replica set. (That is, you cannot set up a standalone instance in Atlas.)

Good luck.

@Simon_39939

On other thing you should note, the POCDriver docs specifically say

If you are running a mongod with '--auth' enabled, you must pass a user and password with read/write and replSetGetStatus privileges (e.g. 'readWriteAnyDatabase' and 'clusterMonitor' roles).

So if you’ve only set up ‘readWriteAnyDatabase’, your connection will fail since the user does not have the required privileges. HTH.

Thanks David. Turns out there was nothing wrong with the connection string, I just needed to add the clusterMonitor role to my user and then it worked. I also added a -d 31 parameter to stop running after 31 seconds otherwise it appears to run indefinitely.

And the reason the video’s connection string includes multiple hostnames is because it’s using the mongodb:// standard connection string, which seems to require all the hostnames for a replica set, whereas I’m using the newer mongodb+srv:// DNS seedlist connection string which allows me to specify a single hostname which takes care of resolution of all the other hostnames on the server side. I haven’t yet worked out how to build the mongodb:// style connection string, I think I may be supplying the wrong value for the replicaSet parameter. Although at the moment I can’t think of any reason why I’d need to use the older format now that the mongodb+srv:// format is available.

Oh, and there was no need for me to include the /test part, as this determines the database to authenticate against, I just needed to end the hostname with a / and it defaults to authenticating against the admin database.

I’ve registered for M103 too, in the hope of understanding the differences between standalone, replica sets and shards.

Thanks again :slight_smile:

I’ve just watched the first video in chapter 5 and now I think I get the idea of replica sets and shards.

A given document will be present in every node of a replica set (once we’ve waited for the replication to happen), but in a sharded cluster it’ll be present in only one of the shards. And if that shard is itself a replica set, which seems to be best practice, the document is present in every node of the replica set of that one shard.

@Simon_39939

Exactly! Good work.