0

full disclosure: I am a complete n00b to mongodb and am just getting my feet wet with using mongo on AWS (but have 2 decades working in IT so not a total n00b :P)

I setup an EBS volume and installed mongo on a EC2 instance. My problem is that I provisioned too small an EBS volume initially. When I realized this I:

  1. created a new larger EBS volume
  2. mounted it on the server
  3. stopped mongo ( $ sudo service mongod stop)
  4. copied all my /data/db files into the new volume
  5. updated conf files and fstab (dbpath, logpath, pidfilepath and mount point for new volume respectively)
  6. restarted mongod

When I execute: $ sudo service mongod start
- everything runs fine. - I can futz about in the admin and local databases.

However, when I run the mongos command: > show databases
- I only see the admin and local. - the database I copied into the new volume (named encompass) is not listed.

I still have a working local copy of the database so my data is not lost, just not sure how best to move mongo data around other than:

A) start all over importing the data to the db on the AWS server (not what I would like since it is already loaded in my local db)

B) copy the local db to the new EBS volume again (also not preferred but better that importing all the data from scratch again!).

NOTE: originally I secure copied the data into the EBS volume with this command:

$ scp -r -i / / ec2-user@:/

then when I copied between volumes I used a vanilla cp command.

Did I miss something here?

The best I could find on SO and the web was this process (How to scale MongoDB?), but perhaps I missed a switch in a command or a nuance to the process that rendered my database files inert/useless?

Any idea how I can get mongo to see my other database files and collections? Or did I make a irreversible error somewhere along the way?

Thanks for any help!!

Community
  • 1
  • 1
taoteg
  • 183
  • 1
  • 1
  • 11

2 Answers2

0

Are you sure you conf file is being loaded? You can, for a test, load mongod.exe and specify the path directly to your db for a test, i.e.:

mongod --dbpath c:\mongo\data\db (unix syntax may vary a bit, this is windows)

run this from the command line and see what, if anything, mongo complains about.

E.J. Brennan
  • 45,870
  • 7
  • 88
  • 116
  • From the command line: $ mongod -dbpath /data/dba I get this: exception in initAndListen: 10309 Unable to create/open lock file: /data/dba/mongod.lock errno:13 Permission denied Is a mongod instance already running?, terminating ... couldn't remove fs lock errno:9 Bad file descriptor It looks like it is finding a lock but the only lockfile is the one that seems to be working. From the mongo log I see a succesful launch. So how do I ensure mongo is loading my mongod.conf file in /etc then? Thanks for clueing me in! I will investigate the conf file further. – taoteg Apr 03 '14 at 19:56
  • does mongod.exe process have full permissions to the directory? – E.J. Brennan Apr 03 '14 at 20:41
  • I checked the mongod process again on the server and it is definitely running with -f /etc/mongod.conf args under the mongod user who owns all the data directories. Now I'm checking individual file permission settings within the dirs. I am trying out the mongodump/mongorestore process (dumping from my local working db and restoring to the EC2 server once I push the output to the attached S3 storage in the cloud). While running that process (my lowly DSL connection takes a while to push even 16 GB into the S3 bucket) I am continuing to see if I can find anything else wrong. – taoteg Apr 03 '14 at 23:27
  • I am still thrown as to why running '$ sudo service mongod start' works without a hitch (except no databases I want - which could be bad to begin with) while running '$mongod -dbpath /data/dba' throws lock errors and exits. Wouldn't they both refer to the same thing since the service is using the /etc/mongod.conf that points to /data/dba to begin with? I am starting to think my cp process just failed utterly and my data is bad on the server. If nothing else emerges before I get that mongodump pushed, I will at least know I followed a more official procedure to start with! – taoteg Apr 03 '14 at 23:32
0

A database has a very finicky algorithm that is easy to damage. Before copying from one database to another you should probably seed the database, a few dummy entries will tell you the database is working.

Jonathan Engwall
  • 71
  • 6