I'm trying to copy all the data from my localhost default meteor mongo database to the production server to use it in "app.meteor.com".
I tried to use mongorestore usinng the information provided by "meteor mongo --url app.meteor.com", but it does not modify any document.
Moreover, when I connect to mongo database of the server, I can only read (find) documents. When i use update or insert functions it says "not master"
Run
~/meteor/meteor mongo -U yoapp
You will get something like this
mongodb://client:387shff-fe52-07d4-69a4-ba321f3665fe7#c0.meteor.m0.mongolayer.com:27017/yoapp_meteor_com
Take the values and put into mongorestore like this
mongorestore -u client -p 387shff-fe52-07d4-69a4-ba321f3665fe7 -h c0.meteor.m0.mongolayer.com:27017 -db yoapp_meteor_com /home/user/dump/yoapp
I just dumped a prod app to my local dev machine. Testing some new changes. Pushed code to a staging install on meteor.com and then used mongorestore to populate the staging database.
Moreover, when I connect to mongo database of the server, I can only read (find) documents. When i use update or insert functions it says "not master"
It's probably because the server you are connecting to is not a MASTER, but a SLAVE in a replica-set. Slaves are readonly and all writes need to be directed to the master. You can get the master hostname:port by querying rs.conf() and looking at the entries in members. See http://docs.mongodb.org/manual/reference/replica-configuration/
Get the master and then try mongoimport/mongorestore on it.
You should also tail the mongod logs on your production server, to see if there are any errors on import (provided you have access).
Related
I have app running against local mongo on server with ip xxx.xxx.xxx.xx. I would like to dump data using mongodump. I ssh to the server. First i checked if mongo is running are data are there. I did mongo and show dbs, I see list of dbs. Now I did use app and show collections data are there. So I tried mongodump --db app and I see in console
connected to: 127.0.0.1
2021-10-28T11:12:03.321+0000 DATABASE: app to dump/app
Great, but only thing it did, it created dump/app folder. But folder is unfortunately empty. What I do wrong?
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).
What are best practices for synching users and roles between Mongo instances?
On the same Windows machine, I am trying to copy MongoDB users and roles in the admin database from one Mongo instance to another. Authentication is 'on' for each instance. No combination of mongodump\mongorestore or mongoexport\mongoimport I have tried works. With mongodump\restore, the restore step displays:
assuming users in the dump directory are from <= 2.4 (auth version 1)
Failed: the users and roles collections in the dump have an incompatible auth version with target server: cannot restore users of auth version 1 to a server of auth version 5
I found no command line option to tell it not to do this silly thing. I have Mongo version 4 and that's it installed.
You would think --dumpDbUsersAndRoles and --restoreDbUsersAndRoles would
be symmetrical, but they are not.
I was able to run this,
mongoexport -p 27017 -u admin --password please -d admin --collection system.roles --out myRoles.json
However, when trying mongoimport
mongoimport -p 26017 -u admin --password please -d admin --collection "system.roles" --file myRoles.json
the output displays
error validating settings: invalid collection name: collection name 'system.roles' is not allowed to begin with 'system.'
Primer
Users are attached to databases. Ideally, you have your database specific users stored in the respective database. All “global” users should go into admin. The good part: replica sets take care of syncing those users to each member of the replica set.
Solution
That being said, it seems to be quite obvious on how to deal with this.
For a worst case scenario, it is much easier to have a .js ready which simply recreates the 3-4 global roles instead
of fiddling with system.* collections in the admin database. This has the advantage that you can also do other setup stuff automatically, like sharding setup if TSHTF and you need to rebuild your cluster from scratch.
use admin;
db.createRole([...])
db.createRole([...])
// do other stuff, like sharding setup
Run it against the primary of your replica set or a mongos instance (if you have a sharded cluster) using
mongo daHost:27017/admin myjsfile.js
after you set up your machines but before you enable authentication.
Another option would be to use Ansible for user creation.
As for dump and restore, you might want to leave out the collection name.
I am setting up a Mongo DB database on mongolab. I have 2 small documents in a single collection in my local db server, that I want to upload. I used mongodump to export that to a collection.bson and collection.metadata.json file
When I use mongorestore I get an error:
Failed:database.collection: error restoring from /tmp/mongodump/database/collection.bson: insertion error: EOF
collection.bson is less than 2KB. My research shows that this error shows up when your database is huge, but not very small. I can't get anything for my situation. The common solution of using --batchSize 1 results in the same issue.
After I run mongorestore the collection does exist on the remote, but it is empty (0 documents)
How can I get my tiny local db up on my remote server (on MongoLab).
I am locally running mongo3.4, but my MongoLab instance is 3.2.13. I'm wondering if the problem is the mismatch of versions?
mongorestore command:
mongorestore -h ds111882.mlab.com:11882 -d database -u username -p password /tmp/mongodump/database
mongodump
mongodump -d database -o /tmp/mongodump
Additional info: I imported the mongodump I created into another local database (also running 3.4) and it worked just fine, but restoring to the mongolab server causes the error.
Also a bsondump of the generated collection.bson file creates a json file with the correct 2 documents.
Found the answer, it is an issue with versions. My schema was using the Decimal128 type, which isn't supported in 3.2. Downgrading to Double (didn't need Decimal128 anyway) fixed the issue.
It might be a dead simple question yet I still wanted to ask. I've created a Node.js application and deployed it on Heroku. I've also set up the database connection without having any trouble as well.
However, I cannot get the load the local data in my MongoDB to MongoLab I use on heroku. I've searched google and could not find a useful solution so I ended up trying these commands;
mongodump
And:
mongorestore -h mydburl:mydbport -d mydbname -u myusername -p mypassword --db Collect.1
Now when I run the command mongorestore, I received the error;
ERROR: multiple occurrences
Import BSON files into MongoDB.
When I take a look at the DB file for MongoDB I've specified and used during the local development, I see that there are files Collect.0, Collect.1 and Collect.ns. Now I know that my db name is 'Collect' since when I use the shell I always type `use Collect`. So I specified the db as Collect.1 in command line but I still receive the same errors. Should I remove all the other collect files or there is another way around?
You can't use 'mongorestore' against the raw database files. 'mongorestore' is meant to work off of a dump file generated by 'mongodump'. First us 'mongodump' to dump your local database and then use 'mongorestore' to restore that dump file.
If you go to the Tools tab in the MongoLab UI for your database, and click 'Import / Export' you can see an example of each command with the correct params for your database.
Email us at support#mongolab.com if you continue to have trouble.
-will
This can done by two steps.
1.Dump the database
mongodump -d mylocal_db_name -o dump/
2.Restore the database
mongorestore -h xyz.mongolab.com:12345 -d remote_db_name -u username -p password dump/mylocal_db_name/