EDIT:
Not sure what I've done differently (again, these are my first steps with all of this), but now I don't get the error message I got before. Instead though, it just tries to make the connection and I get
Server selection timed out after 30000 ms
After some time.
ORIGINAL:
I am new to using MongoDB - currently taking a back end course online.
It seems that Compass has changed their interface for adding a new connection, lately, and maybe some business logic, because all guides I find use the previous one.
Specifically, when adding a new connection, in the guides I read, they leave Replica Set Name empty. When I try to do that, I get an error saying Incomplete key value pair for option.
I tried just calling it localhost and it "works", but I don't see any of my DBs.
If I connect with Robo 3t I can see them.
Is it a wrong Replica Set Name that's preventing me from deeing the DBs? Or am I doing something else wrong?
My settings for when trying to connect are:
Hostname : `localhost`
port : 27017
SRV record : I leave it off
Authentication : None
Replica Set Name : localhost
Read preferences : Primary
SSl : none
SSL tunnel : None
It appears that Compass requires a replica set name to be specified, based on the following message I get when I specify a single host which happens to be a secondary:
An error occurred while loading navigation: 'not master and slaveOk=false': It is recommended to change your read preference in the connection dialog to Primary Preferred or Secondary Preferred or provide a replica set name for a full topology connection.
"Server selection timed out" can mean different things:
There isn't a database running.
The database is running but you entered the wrong port number.
Compass attempted to perform a specific operation which required a certain server type (e.g. a primary or a secondary). The database is running and there's a server listening at the port you specified, but it is of the wrong type.
Hard to say which of these is the case just going by the error message.
I had the same problem working on a single machine for development as a replica set member(primary). I did this because I had to use #Transactional of spring-data-mongodb. What solved for me was logging to mongo shell and issuing:
rs.initiate();
Related
I'm using Postgres with row-level security to lock down all queries across tables to a particular tenancy. I do this by calling a SET app.tenant_id = x; statement each time my service opens a connection, and my RLS policies use this session-level setting to limit the return data. Basically the approach described here under 'Alternative Approach'.
If this service is deployed in AWS, with RDS Proxy in between it and the database then I understand it'll be subject to 'connection pinning' since I'm using a SET statement. I'm trying to get a feel for how big an issue this actually is. A few questions:
Are SET LOCAL statements also going to cause pinning?
If my service connections to RDS Proxy are short-lived and a single transaction (which they will be 99% of the time) does this lessen the impact?
Does service connection pooling (service -> RDS Proxy) help or hinder?
Basically any advice on how much of an issue this is, how I can make this work, or any workarounds, would be appreciated.
I had to delete my previous answer because I was originally using pgAdmin, which is apparently very keen on pinning connections. This meant I couldn't trust my data. I have redone this experiment with another more well behaved tool, psql.
I understand where you're coming from. According to the documentation, SET will cause pinning, but it's unclear if that includes SET LOCAL. Since I need this information too, I will run a test today and post the results here.
I will do the following
Step 1: Open one connection through our proxy and use a regular SET so ensure that the DatabaseConnectionsCurrentlySessionPinned metric increases to 1. I will use the following query:
SET search_path TO blah;
SET app.tenant_id TO 123;
Step 2: I will close that connection and see that the metric decreases back down to 0.
Step 3: I will open a new connection, but this time I will use the following query:
SET LOCAL search_path TO blah;
SET LOCAL app.tenant_id TO 123;
Step 4: I will close the connection, and if the connection is pinned, I will monitor the metric to see if and when it decreases back to 0.
Let's do this
Caveat: don't look at the metrics in RDS Management Console. See: https://repost.aws/questions/QUfPWoiFxmR7-lios5NrFwBA/fix-database-connections-currently-session-pinned-metric-on-rds-proxy-dashboard
Step 1
The connection between proxy and server was pinned immediately when I ran SET commands, as expected.
Step 2
The pinned connection between proxy and server was closed immediately when I closed the connection between client and proxy.
Step 3
The connection between proxy and server was not pinned when I ran SET LOCAL commands.
Step 4
The connection was not pinned, so this step is superfluous.
Conclusion
SET LOCAL does circumvent pinning in RDS Proxy, with the caveat that it must be done within a transaction.
In my previous attempt to answer this question, pgAdmin's behavior made me conclude that pinning does occur in both cases. This is wrong.
To answer your other questions, if pinning does occur, it doesn't matter that your transactions are short. The server connection will remain pinned until the client connection is gone. Your only resort is to make sure you close client connections once they're pinned.
The documentation states that "when a connection is pinned, each later transaction uses the same underlying database connection until the session ends. Other client connections also can't reuse that database connection until the session ends. The session ends when the client connection is dropped."
I've been using Mongo for a while now, and I never had any kind of errors. But today, I tried running the mongo command in my terminal and I got the following error:
Error connecting to 127.0.0.1:27017 :: caused by :: No connection could be made because the target machine actively refused it. :
I have my PATH variable for Mongo properly configured in my environment variables as follows:
C:\Program Files\MongoDB\Server\4.4\bin
so I doubt that is the issue. I remember going through my task manager yesterday and I accidentally terminated a program running in the background related to Mongo, but I can't seem to remember exactly what it was called, and I really think that that's the root of my problem, because before having terminated that Mongo program in my task manager I had never ran across this connection problem before.
By terminating a program in the background, I'm going to assume you didn't just end process, otherwise a simple computer restart would fix your issue. And in some cases, that same program would've relaunched when you launched MongoDB. But if you disabled a service and need to find which service needs to be running to be able to connect to your MongDB then I would suggest going through your Windows Services list and seeing which ones you disabled and looking one relating to TCP or SNMP.
This is because MongoDB Wire Protocol is a simple socket-based, request-response style protocol. You communicate with the database server through a regular TCP/IP socket and since you can't remember which one you "terminated" and any number of services related to networking can cause a dependency to be absent, I can't be more specific in helping you determine which one you need to turn back on and you'll have to do it through trial and error but I can at least offer you some guidance, hopefully.
Specifically you can either
Run system configuration using
msconfig
In a run box, navigating to the Services tab, order the list by Date Disabled to find the service that was disabled which correlates with when you when snooping through task manager, or
Run Task manager and navigate to the Services Tab, then Open Services, and order them by Status or by Name, and look for any service that includes TCP/IP, COM+, Port direction, etc. to see which one is disabled and change the configuration from anything but Disabled and then stat it manually and run MongDB again.
It's about as specific as I can get without knowing anything more than you terminated some program running in the background but I hope it helps.
The background process (daemon) for MongoDB is called 'mongod'. It's an executable in your bin directory inside your mongodb installation. You can just execute it in the terminal.
Run:
C:\Program Files\MongoDB\Server\4.4\bin\mongod.exe
I signed up freely at MongoDB Atlas and created cluster now I want to know how can I create database and connect to that using Robomongo?
1) (Atlas Mongodb console)First of all click on ALLOW ACCESS FROM ANYWHERE(see in below image) and put some random IP address , don't click on Add Current IP Address otherwise it will not connect with robomongo .
2) Now open robomongo ,select connection Tab and then select type Direct Connection , and put your primary cluster in Address [you can get your Primary Cluster Address from Project->Clusters->(choose) Primary Cluster-> "There you will find your Primary Cluster Address"] .
3)now click on Authentication Tab , put database name is admin and put your username and password , Auth Mechanism is SCRAM-SHA-1.
4) select self-signed certificate as Authentication Method
5) Now , click on test,we are done !
The standard Mongo URI connection schema has the form:
mongodb://[username:password#]host1[:port1][,...hostN[:portN]]][/[database][?options]]
Security Reasons
Do not allow access everywhere for security reasons
Restrict to your IP address
Connect via roboMongo 3T using a secondary cluster node from MongoDB Atlas
In case it helps others, Robo3Tversion 1.3 and greater has a "From SRV" field where you can paste the SRV connection string and it fills out the connection options correctly for you. As of 1.3 it looks like this:
As of writing, you can get the connection string by clicking the "connect" button next to your cluster dashboard's graphs, and then clicking "Connect your application", and you get a screen like this with the connection string that you can copy:
#kdblue, It's not working for me. But when I tried using the replica set, I could able to connect successfully.
Robo 3T Version: 1.2.1
Steps followed:
In your MongoDB Atlas(cloud.mongodb.com), copy all the three replica sets name and note it down. (Refer an image for reference, the replica sets denoted in the orange box).
Now, in your Robo 3T, in Connection tab, select type as Replica Set.
Provide a suitable name for your connection.
And now in Members, add all the three copied replica sets. Refer image for details.
Provide authentication, if you have any and follow SSL steps (mandatory) as suggested by #kdblue in the previous answer.
You could able to connect successfully now.
Thank you.
[Updated]
It is now possible to connect to Mongo Atlas 3.4 free cluster with the latest beta: Robomongo 1.1 - Beta version with MongoDB 3.4 Support
Direct connections do not work with Replica Sets and Robo3T.
And the cluster you create on Atlas is a 3-Node replica set.
Select Connection Type: Replica Set on the first tab
To find out 3 members in new Atlas dashboard:
click on Clusters in your Atlas dashboard.
click collections button on the cluster.
click Overview tab on the next menu.
you will see the list of your set (primary and two secondary).
then follow #Balasubramani M's answer.
If you have the "TLS" instead of the "SSL" tab, don't get crazy.
Just do exactly the same that you would do with "SSL":
Mark the "Use TLS protocol" checkbox
Choose the "Self-signed Certificate" authentication method option
And that's all!
Instead of connecting it with robomongo I would recommend you to connect it with COMPASS. That is a opensource GUI tool for connecting to your MongoDB Atlas deployment and it is supported by MongoDB people also.
You can download compass from https://www.mongodb.com/download-center/compass.
Additionally many functionalities are not supported in robomongo.
Robo mongo is the 3rd party tool so even if you go the mongodb people they will not support.
Instruction for connecting your atlas cluster with compass can be found in the documentation https://docs.atlas.mongodb.com/compass-connection/
However, even after following my response you encounter any issue, let me know , I will help you further.
No matter what I tried it wouldn't work, all I had to end up doing was update to the latest version at which point my old connection setup worked fine.
https://robomongo.org/download
Tip: I struggled updating a connection, no dice.
Created one form scratch using above and connected on first attempt.
I'm trying to get a Play (2.1) app with ReactiveMongo (0.9) working on the app's test server. However, when our application is run on my dev box, is able to store image metadata just fine, even pointing to the mongo 2.2 install on the mongo test server. Even ran it with "play stage", then run directly with java 1.6.0. However, run the same way, also with Java 1.6.0 on the test server, the app continuously logs this error:
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
r.c.a.MongoDBSystem - The entire node set is unreachable, is there a network problem?
And not just during initialization... it repeats indefinitely. I've seen this error mentioned elsewhere, but I don't think those solutions apply to this. From the app's test server, I'm able to telnet to port 27017 on the mongo test server successfully. I see both my local install and the test server install of the app log that it's using the same mongodb url.
So based on what I said, I believe I can eliminate:
Blocked port
Mongo server down
Pointing to wrong mongo server
Mongo version mismatch
Java version mismatch
I'm going through the reactivemongo source but it seems the error is spewed when the MongoChannels are not set as authenticating or ready state (usable). I'm planning to try remote-debugging to see where it's going wrong, but I'm running out of time on this, so I'm hoping for a troubleshooting tip or two if I can get any.
Thanks!
Alright, figured it out. We're running Casbah/Salat on the same app, for now. There's a mongodb.uri in the config file that gets read in by both. However, ReactiveMongo seems to only work if the database name is included, which according to the mongodb "connection string uri" spec:
http://docs.mongodb.org/manual/reference/connection-string/
... you only need to include the database if you have credentials you need to authenticate with. In our case, we don't have credentials, so Casbah wasn't including the database. I added it in anyway... casbah ignored it safely, and reactivemongo worked. I neglected to do the same in the test config file, so even though it was showing the correct host, it wasn't about to work correctly.
I see how the host url + db name in one string replaces the two fields "mongodb.servers" and "mongodb.db", but it can be confusing if not conforming to mongo's similar spec.
I have a sharded cluster which has a replica set sharded, my application layer is talking to mongos , and now if my primary server goes down, my php application throws an error. I know this is because I have not enabled setSlaveOkay from the driver by doing something like this:
MongoCursor::$slaveOkay = true;
The problem with this is, where ever I am talking to db I have to add this statement.
Is there a way that I could enable this in the system level?
I tried doing rs.slaveok() in my primary and secondary both but still my application layer is throwing an error .
I also tried db.getMongo().setSlaveOk() in mongos console
The error statement is as follows:
PHP Fatal error: Uncaught exception 'MongoCursorException' with message 'dbclient error communicating with server: testserver:10001'
You can set slaveOK at several levels in PHP: connection, database, collection, or cursor.
The various details are to be found here:
http://php.net/manual/en/mongo.queries.php
You are setting it for each cursor, which is why you are having to call it so often. Instead you can set this at the db or collection level. In terms of what is happening behind the scenes - slaveOK is actually set for each connection - PHP is just managing that for you when you set it for the database, collection, cursor etc.
Setting it at the mongos or anywhere else in the shell simply sets it for that connection. Once you log out, it is no longer set.