I have a mongodb in a replica set running with a cloud provider called compose.io.
I just created a new Google cloud compute mongodb cluster using these instructions
I want to copy all the data in my compose database to the compute instance.
One path I have been following has led me to get a file system backup of the running database and store it locally. I have opened that database locally and executed mongodump (I didn't seem to have permission to do that against the remote database) so I have the output of mongodump and a file system copy of the database stored on my machine.
I have no idea how to get any of this in to the compute cluster I created. I don't seem to be able to run mongorestore although figuring that out is still my main path at the moment. I am getting authentication errors which may be my not getting the command right or a database configuration issue. I am not sure yet.
I tried mongorestore from my local machine to the machine holding the primary database in the replica set.
Edit:
The last thing I tried was copy scp the mongodump output on to that machine and run mongorestore there.
I got this error:
2015-01-28T23:35:40.303+0000 Creating index: { key: { _id: 1 }, ns: "admin.system.users", name: "_id_" }
Error creating index admin.system.users: 13 err: "not authorized to create index on admin.system.users"
Aborted
Now I don't seem to be able to run any commands in mongo that require any kind of privileges, such as list database. Tried passing credentials for users that existed in the original database but that is not working so far.
Here is one possible fix.
Turn off auth in mongod.conf:
# mongod.conf
#auth=false
noauth=true
Run the mongorestore, then restart mongod with auth enabled.
Related
mongodump was used long time ago to create a backup, now in order to restore the database for a Meteor app, this command was used:
ais2> mongorestore C:\Users\AAA\Documents\meteor\apps\dump\dump\
PS C:\Users\empl1\Documents\meteor\apps\ais2> mongorestore C:\Users\AAA\Documents\meteor\apps\dump\dump\
preparing collections to restore from
reading metadata for dbais2.dataTeckAllMatchCol from C:\Users\AAA\Documents\meteor\apps\dump\dump\dbais2\dataTeckAllMatchCol.metadata.json
reading metadata for dbais2.makeModelCol from C:\Users\AAA\Documents\meteor\apps\dump\dump\dbais2\makeModelCol.metadata.json
reading metadata for dbais2.usageCol from C:\Users\AAA\Documents\meteor\apps\dump\dump\dbais2\usageCol.metadata.json
reading metadata for dbais2.vehiclesDetailsCol from C:\Users\AAA\Documents\meteor\apps\dump\dump\dbais2\vehiclesDetailsCol.metadata.json
restoring dbais2.dataTeckAllMatchCol from C:\Users\AAA\Documents\meteor\apps\dump\dump\dbais2\dataTeckAllMatchCol.bson
restoring dbais2.makeModelCol from C:\Users\AAA\Documents\meteor\apps\dump\dump\dbais2\makeModelCol.bson
restoring dbais2.usageCol from C:\Users\AAA\Documents\meteor\apps\dump\dump\dbais2\usageCol.bson
restoring dbais2.vehiclesDetailsCol from C:\Users\AAA\Documents\meteor\apps\dump\dump\dbais2\vehiclesDetailsCol.bson
finished restoring dbais2.dataTeckAllMatchCol (11705 documents, 0 failures)
Since I have a directory "dbais2" with all the database files located in the above path.
In a new shell ais2> meteor mongo opens a mongo shell, but show dbs does not show the "dbais2". How can I use the newly restored database? or it was not restored correctly? if so. how to restore it correctly?
Thanks
When you run mongorestore as is, it will connect to the mongo instance running on port 27017 on your local machine (if any). That's what you would use in production. Since the restore succeeded, it must be that you have such an instance running. In that case, run mongo ais2 to connect to that instance and db.
In development, meteor runs its own mongo instance on port 3001 (assuming you used meteor on the default port 3000). When you run meteor mongo that is the instance your shell will connect to. If you want to restore into that, then rerun your command with the port specified:
mongorestore --port=3001 -d meteor C:\Users\AAA\Documents\meteor\apps\dump\dump\
After that you should see your data in the shell opened by meteor mongo. Note that in this command I'm also overriding the database name, so that the data will be imported into the database used by meteor in development (also called meteor).
I have a backup of /data/db that contains all .wt files along with journal directory etc. I have stopped the db, replaced the current db directory with the one backed up and started the db. This works, Mongo starts up but when I "show databases" there are no results. The local machine (that was backed up) did not have authentication enabled. The machine I am using to attempt the restore does have it enabled, I am able to start the mongo client without any authentication.
Is there another step to this process?
Is the authentication difference an issue?
I am on Linux Server. My MongoDB Database is stored there. Now if I want to delete the database from another machine lets say my development machine, then for that I created the steps but not working for me.
create a delete.sh file
#!usr/bin/env mongo
#instance Ip assume:
mongo 12.122.12.12:27017/tempDatabase --eval "db.dropDatabase"
But I am unable to delete the Database. Any idea that where I have done mistakes. Any interaction is really appreciated
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:
created a new larger EBS volume
mounted it on the server
stopped mongo ( $ sudo service mongod stop)
copied all my /data/db files into the new volume
updated conf files and fstab (dbpath, logpath, pidfilepath and mount point for new volume respectively)
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!!
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.
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.
I am migrating from server OLD at the old hosting company to server NEW at the new hosting company.
I want to run the clone command so I clone the mongoDB from OLD to NEW.
For OLD:
The public ip address is: 44.55.66.77.
The machine login user name is: admin, and the password is password
What is the right way to do this?
So far I can't even log into the server OLD
So far I have tried the following command prompts on NEW:
mongo -u admin -p password 44.55.66.77
mongo remote-ip:44.55.77.66 -u admin -p password
That don't work
I also tried this from mongo shell:
db.CopyDatabase('OldDb', 'NewDb', '44.55.66.77', 'admin', 'password')
and I get: the "could not connect to server" error message
Aside from firewall considerations in order to copy data between MongoDB servers, db.copyDatabase() (aka the copydb command) has a number of important usage caveats including:
copydb does not produce point-in-time snapshots of the source database; writing data to the source or destination database during the copy process will result in divergent data sets
copydb does not lock the destination server during its operation, so the copy will occasionally yield to allow other operations to complete.
There is also a known issue that copydb may not work with the role-based privileges in MongoDB 2.4 if you have authentication enabled (see SERVER-8213, which was recently fixed in the 2.5.x development releases).
A much better approach to migrating your data would be to restore from a normal backup using mongodump/mongorestore or file system snapshots. The Backup & Recovery section of the MongoDB manual has tutorials covering procedures for different deployment types.