I am using Docker to add mongodb 2.6.5 to a host that already had 2.4.9 installed and I am sharing the data directory.
When I run the 2.6.5 (in container) I get permission issues apparently due to changes in 2.6:
http://docs.mongodb.org/manual/tutorial/add-user-to-database/
But when I try to add a user with role roleAdminAnyDatabase I get "No role named roleAdminAnyDatabase#admin"
Do I need to migrate the data? What is the best way to do that?
I assume I could start up 2.6.5 with no data files and mongorestore the data from 2.4.9. But, does that mean I cannot run 2.4.9 using that directory anymore?
Related
I have a MongoDB instance with two databases, let's call them "realdb" and "copydb".
All I want to do is to periodically copy realdb to copydb. The copydb database is our "testing" instance of the actual database "realdb", and we want to periodically update it.
Normally the answer to this question would be "copydb" or "export/import". However, there are some challenges:
The target Mongo instance is running version 1.6 and is not likely to be updated anytime soon.
The target Mongo instance is on a remote server to which I don't have direct access.
This seems like basic enough a function that even 1.6 should have the ability to do it. But when I try anything I get "No such cmd" errors as if the newer Mongo can't communicate with the ancient Mongo.
Any thoughts on how this could be done?
The error "no such command" might mean that:
The command was mistyped, or does not exist
There is a mismatch of the client version (e.g. mongo shell, mongodump, mongoexport, or a mongodb driver) and the server version.
In this case it was a mismatch of the mongo shell version (3.4) vs server version (1.6).
I have a mongodb production database running on mongo 2.4.8 and I would like to upgrade to 2.6.x.
The way we want to do that is first load the data to another server running 2.6.3 using mongorestore. However when running the mongorestorecommand we get the following error:
Cannot restore users with schema version 1 to a system with server version 2.5.4 or greater
I cannot find anything related to this issue and do't know what to do. In case it matters, the database itself was not created from scratch with mongo 2.4.x but with previous versions.
What ca I do ? Is there another way of doing this other than using mongorestore ?
Thank you in advance for your help ...
There are two approaches you can take to upgrade your user schema with the 2.4 mongodump.
1) Restore into MongoDB 2.4 and then upgrade to 2.6
This follows the normal 2.6 upgrade path. Instead of trying to mongorestore your 2.4 backup directly into 2.6, restore into a 2.4 instance and then upgrade to 2.6.
It is recommended that before upgrading, you run db.upgradeCheckAllDBs() via a 2.6 mongo shell. This checks for any potential compatibility issues due to changes in MongoDB 2.6. For example, 2.6 implements stronger enforcement of index field definitions and key length restrictions.
2) Restore into MongoDB 2.6 using 2.4 mongorestore and then upgrade the user schema
This approach requires the MongoDB 2.4 version of mongorestore
start up your MongoDB 2.6 mongod without auth enabled
mongorestore your backup using a 2.4 version of mongorestore
run the authSchemaUpgrade command in your 2.6 mongo shell:
db.adminCommand({authSchemaUpgrade: 1 });
restart your 2.6 mongod with auth enabled
Three approaches that I can think of:
First, if you are running as a replica set, I'd upgrade the members
one by one. If you're not running as a replica set that's bad,
MongoDB is really not designed for production usage with a single
instance. Details on converting to a replica set and in a rolling
upgrade here:
http://docs.mongodb.org/manual/release-notes/2.6-upgrade/ and here:
http://docs.mongodb.org/v2.6/tutorial/convert-standalone-to-replica-set/#
Second, if you are running on a file system that supports snapshots
(like Amazon EBS or Linux LVM) you can snapshot the database files,
restore to a new file system and start up a new mongod process using
2.6. http://docs.mongodb.org/manual/tutorial/backup-with-filesystem-snapshots/
Third, try exporting the data via mongoexport and loading it via
mongoimport. It's not the same as mongodump/mongorestore so it has
some limitations (it's not a full backup of the database, just a
text dump of the collections) but might help you get past this issue
with mongorestore: http://docs.mongodb.org/v2.6/core/import-export/
When I meteor deploy my app, it seems to create an entirely new mongodb instance. I'd like to be able to deploy with the current mongodb have locally.
Same goes the other way -- I'd like to be able to download the mongodb back to my localhost after it has been deployed.
For clarification, I'd really like to know the follow:
1) how to deploy with a fresh mongodb
2) how to deploy to an existing deployed app without overwriting the old mongodb
3) how to download/sync mongodb locally with the existing deployed app
4) how to make local backups of mongodb
You can perform a mongo dump using meteor mongo to export your local database and deploy your app using Meteor Up which should also allow you to automate the database import and deployment process.
"Meteor Up (mup for short) is a command line tool that allows you to deploy any meteor app into your own server."
You can stop the mongodb service and start a mongod instance in a separate terminal, by just typing mongod. This will let you monitor what's happening on the mongodb instance that you just started.
Open another terminal and do export MONGO_URL=mongodb://localhost:27017/nameOfDBgoesHere
This will create a new DB named "nameOfDBgoesHere" and it won't overwrite what you currently have, unless you name it with the same name.
After that just start meteor by typing meteor in your program's folder. In the mongod terminal that you opened you should see some connections opening.
By default mongodb creates it's DB files in /data/db. If you have another meteor app and follow the same steps in another terminal, while keeping the name of the DB you specified in the MONGO_URL you will just connect to it from that app - without overwriting anything.
As for the syncing with a deployed app and the local backups of mongo - it seems like something that the mongodb website covers, but maybe someone can chime in here. Not sure if there is a meteor specific, easy way of doing this.
I have my MONGO_URL set to mongodb://localhost:27017/meteor and have the MongoDB run as a service.
When running my project it seems OK to store data to the separate MongoDB until I tried to run meteor reset.
My assumption is it tried to remove its default database. The error complained that myproject.meteor\local is not empty and pointed to fs.js:456 which goes to files.js:256 (rm_recursive) and so on.
any idea what and how I can fix this?
$ meteor reset only resets the bundled MongoDB. It won't reset an external Mongo database.
(That's something we should explain better in the documentation.)
In your case, try connecting to the Mongo database directly (with the mongo command line shell) and running > db.dropDatabase()
situation
Hello, I run arch Linux for which there is no meteor package and have an Ubuntu server run within virtualbox for web development. There is a shared folder I mount through database. hich means I can code in to the active environment.
However, like many others, I have a problem with mongodb starting up, specifically the exit code 100.
tracing the problem:
I created the /data/DB directory
gave access rights to my user
ran mongod on its own with no problems
Still I have the issue though.
Question
Where is the configuration file for mongodb which is installed with meteor so I can move it and do I need to create rights for a 'mongodb' user?
Question
What would be the ideal virtual machine for running a meteor development environment in the above set up? Having to create the data directory in the first place tells me Ubuntu server isn't ideal. some extra documentation available to answer this second question appearing on the meteor website would be beautiful
MongoDB does not work correctly on virtualbox shared folders. By default, meteor creates a mongo database in your project's directory, however you can override this behavior with the MONGO_URL environment variable. If you set this variable, meteor will not try to start mongo and will instead connect directly to the mongo endpoint you specify. This allows you to setup mongo however you like (eg using the Ubuntu mongodb package), with data somewhere not in the shared folder.