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/
Related
My customer uses mongoDB 2.4 and as there are some limitations with this version, we have give them the option to upgrade to Latest stable mongoDB 3.4.5.
Initial testing of using
mongodump in MongoDB 2.4
and mongorestore in Mongodb 3.4.5 worked fine as I can see all the collections imported.
From the documentation mongorestore it was not mentioned anywhere that it can restore the dumps from older versions of mongoDB.
As we cannot use the mongorestore , Can I use "mongoexport" to export the data in csv/json format of older mongoDB 2.4 , and import into newer version of mongoDB 3.4 ?
What are the possible problems of using "mongoexport/mongoimport" instead of "mongodump" to upgrade to newer version of mongoDB 3.4 ?
NOTE: I will remove the older version of mongoDB completely and will install the newer version of mongoDB
Mongodump and Mongorestore are better because:
They run faster
They preserve some data formats better than mongoexport and mongoimport, because the data is not translated from BSON into JSON and back.
As described in the MongoDB Docs on MongoImport:
WARNING
Avoid using mongoimport and mongoexport for full instance production backups. They do not reliably preserve all rich BSON data types, because JSON can only represent a subset of the types supported by BSON. Use mongodump and mongorestore as described in MongoDB Backup Methods for this kind of functionality.
In addition, be very careful about the upgrade using mongorestore; just because the data is restored as it was previously, this does not mean that the new version of MongoDB can work with it. For example there were a sequence of changes to the authorisation model after v2.4 which means that you must first upgrade to v2.6, and only then to v3.0. There are similar structural changes at each major version, so it is recommended that you upgrade stepwise, one major version at a time i.e.
v2.4 -> v2.6
v2.6 -> v3.0
v3.0 -> v3.2
v3.2 -> v3.4
From http://www.dba86.com/docs/mongo/2.4/core/import-export.html, mongoexport is supported from 2.4 version. Hence it should be the right tool for that. But still the document has warning message as well.
Warning:
Avoid using mongoimport and mongoexport for full instance production backups. They do not reliably preserve all rich BSON data
types, because JSON can only represent a subset of the types supported
by BSON. Use mongodump and mongorestore as described in MongoDB Backup
Methods for this kind of functionality.
Hope that helps!!!!
Both tools (by default) will just walk the _id index to fetch the data and then write it out to disk. So, yes, both tools will similarly impact your working set which is why I would generally recommend running them against a secondary (preferably a hidden secondary if possible).
I assume you are looking for a mongodump equivalent of the --fields option from mongoexport to only dump out specific fields. The query option can be used to filter results, but it cannot be used with a projection (to select the fields returned) - this is a feature request that is being tracked in TOOLS-28 but is not yet scheduled.
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'm trying to do a mongo restore with full text search indexes, but it returns the following error.
ERROR: Error creating index joyous.joyous_articles: 16730 err: "bad textIndexVersion: 2"
Aborted (core dumped)
I'm doing this in AWS instance, ubuntu 14.04 and mongo version is 2.4.9
Any kind of help is much appreciated.
This error occurred due to the backward compatibility.Here I've tried to restore a dump from 2.6 version to 2.4.9.
2.6 version of mongo implements a stronger enforcement of the limit on index key.Referred from docs: Compatibility Changes in Mongo 2.6
I've solved this by enabling full text search in mongodb.conf file by adding the following line.
setParameter=textSearchEnabled=true
Restart the mongo services using
service mongodb restart
Then during restore i've skipped the indexes using following command
mongorestore --db joy_db --noIndexRestore dump/joy_db
--noIndexRestore will skip creating indexes during export.
I tried to restore database with mognodb 2.6 and the same error occured, but after reinstalling mongodb to 3.2 it started to work
I'm in the process of upgrading our database to Mongo 3.0, and I'm at the step of upgrading our daily backups process from using mongodump 2.6.1 to 3.0.1, which has has greater performance due to parallelized collection downloads.
I'm running into an issue where the mongodump fails midway through with the error
....
2015-04-10T00:42:54.606+0000 [##############..........] XXX.XXXXXXX 6804841/11236617 (60.6%)
2015-04-10T00:42:57.352+0000 Failed: error reading collection: Closed explicitly.
Out of 8 attempts, 6 of them failed, and 2 of them went through fine. I've been unable to find anything else online about this particular error.
The entire mongodump is around 1TB in size, with thousands of collections. The failure happens somewhere in the middle. The mongodump does actually start up, as many .bson files start accumulating in the disk, and I can see the progress files in the output of the mongodump
When running the same code against a 150GB mongo 2.4 instance, it seems to go fine, it likely hasn't been running long enough to run into the error
The mongo database version I'm dumping from is 2.4, we're planning on upgrading 2.4 -> 2.6 -> 3.0. So we wanted to upgrade the mongodump tool in advance, hoping it would work fine against 2.4 and 2.6.
The current backup servers are using mongodump 2.6.1 against the 2.4 mongo databases, and they have been humming along fine, 100% reliability with the mongodump stage of the backup pipeline
The mongodump backup servers(google compute engine VMs) are located on a separate machine from the mongo servers(hard metal server), and the mongo servers are behind a firewall. So we establish an SSH tunnel between the two machines, then perform a mongodump with the --port command. It looks like so:
ssh -M -N -L 1234:localhost:27017 <remote_ip>
mongodump --port 1234 --username XXX --password XXX --out /tmp/dir
Can anyone give me some hints as to what might be going on? We will need to use mongodump 3.0 when our mongo databases are fully upgraded to 3.0.
UPDATE: Another error I'm getting is
2015-04-14T22:56:37.939+0000 Failed: error reading collection: read tcp XXX.X.X.X:XXXXX: use of closed network connection
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?