MongoDB won’t connect remotely

amazon ec2mongodbremote-access

I have installed mongoDB on a redhat virtual machine on EC2.

The server is running perfectly locally, I can connect and execute commands, etc.
Now, I tried connecting remotely from another virtual machine on EC2 but I can't get to connect regardless how much I'm trying. At first I thought it was a problem of security groups, so I tried enabling all ports from within the group (both virtual machines belong to the same secirity groups) I also enabled connections in the iptables file (and yes, restarted the service) but it still doesn't work… Any ideas on what the problem could be?

the error I get is:

MongoDB shell version: 2.0.2
connecting to: ec2-XXXX.eu-west-1.compute.amazonaws.com/test
Thu Jan  5 13:55:32 Error: couldn't connect to server ec2-XXXX.eu-west-1.compute.amazonaws.com shell/mongo.js:86
exception: connect failed

Thank in advance.

Regarding the "bind_ip" setting, well.. there is no default value for that, I mean there even is no bind_ip line on the mongodb.conf, by default. I was probably expecting something like bind_ip = 127.0.0.1 so that I could comment it out, but it wasn't there, so I tried with bind_ip = 0.0.0.0 but still, it's not working either.

Best Answer

Hopefully this helps. You need to explicitly tell mongodb to listen on non-localhost devices. By default it runs only on localhost.

From http://www.mongodb.org/display/DOCS/Security+and+Authentication:

IP Address Binding By default, a mongod server will listen on all available IP addresses on a machine. You can restrict this to a single IP address with the 'bind_ip' configuration option for mongod.

Typically, this would be set to 127.0.0.1, the loopback interface, to require that mongod only listen to requests from the same machine (localhost).

To enable listening on all interfaces, remove the bind_ip option from your server configuration file.

Update: I guess I was confused myself. I thought the default behavior was different than what was described above. (Maybe it used to be?) In any case, you should check your mongo config file to make sure that you have it configured as you expect.

Related Solutions

Linux – MongoDB best practice against constant power failure

All the mongod.lock file is telling you is that the DB had an unclean shutdown, i.e. was not stopped by an admin, etc.

When running a --repair operation by itself, mongod will attempt to read the existing files, write new files and then swap them. Once complete, it should remove the mongod.lock file, and enable you to startup the database.

If used in conjunction with --repairpath argument, then the repaired filed will be placed at the specified repair path, and the lock file may not be removed, as the original data files have not been repaired, rather new files have been written with the repaired data and the specified path.

A possible flow of working with --repairpath:

Service startup, log message informs you of lock problem, exits.
```
mongod --dbpath=/data/db
```
You run a repair command similar to this:
```
mongod --dbpath=/data/db --repair --repairpath=/data/db2
```
and wait for it to complete.
Once complete, start up mongod from the repaired files path:
```
mongod --dbpath=/data/db2
```
Once confirmed working, you can remove /data/db directory if you desire.

All of this can probably be eliminated by "replacing" the files in /data/db/ by not using the --repairpath option.

In regards to recovery, take a look at Journaling - this creates an operation journal that flushes to persistent disk every 100ms, and when mongod starts up and detects unapplied journal files and applies them, removes the lock file, and starts up the server.

Ubuntu – Is it possible to recover MongoDB databases from .ns and .0, .1, . … files

The .ns .0 .1 etc. files are the data files themselves. If you started a mongod instance with a --dbpath argument pointing at that folder, or if you moved the contents somewhere else and used the option to point there, mongod will attempt to read them as normal.

Since your issues suggest corruption and/or some other issue starting mongod (you should really post the startup messages log files, perhaps in a separate question to address that issue), then there are alternatives. For reference, the most common problems are permissions related, especially when people try to start mongod manually (as themselves) or with sudo (as root) and create problematic permissions in the various directories.

You are correct that mongorestore cannot use these data files directly, but mongodump can read them and dump data from them into the BSON files that mongorestore expects.

The option you want here is dbpath. You mention your path is /var/lib/mongo, so you can run something like this:

mongodump --dbpath /var/lib/mongo -d <database name> -o /path/to/put/files

Optionally you can use --repair here too to fix corruption along with the query options in extreme circumstances to get around corrupted sections (rarely, if ever, needed). The various options are described on the mongodump page:

http://docs.mongodb.org/manual/reference/mongodump/

Once you dump the files out, you can use mongorestore to reimport them into another mongod instance.

Best Answer

Related Solutions

Linux – MongoDB best practice against constant power failure

Ubuntu – Is it possible to recover MongoDB databases from .ns and .0, .1, . … files

Related Topic