Folks,
When running a mongodump command, I get the following error:
assertion: 17369 Backing up users and roles is only supported for clusters with auth schema versions 1 or 3, found: 5
Any suggestions on how to address? MongoDB v2.8
Your version of mongodump might be to old. Running a v2.6 client with a v2.8+ server (with the new auth scheme) will give this error.
In my case I was running MongoDB v3.0 on the server, trying to make a dump with MongoDB v2.6 client. After upgrading mongodb-org-tools to v3.0 on my laptop, the problem went away.
Related
My remote mongodump backup script worked for months until today. I'm suddenly getting this error:
Failed: error dumping metadata: error converting index (<nil>): conversion of BSON value '2' of type 'bson.Decimal128' not supported
mongodump does not work on my remote backup server. However, when I run mongodump on the server when my production database lives, it works. But both servers use the exact same version of mongodump:
mongodump version: r3.4.1
git version: 5e103c4f5583e2566a45d740225dc250baacfbd7
Go version: go1.7
os: linux
arch: amd64
compiler: gc
The only place I've found any reference to this error is a Chinese blog (http://blog.5ibc.net/p/102326.html). However, their problem was that they were using an old version of mongo.
Does anyone know what went wrong or how to fix this?
Solved. The versions of mongodump on the production server and the backup server were the same. However, my script was executing mongodump on the jump server that connects the backup server to the production server. And the jump server had an out of date version of mongo. I don't know why it failed yesterday after running for months. But it worked after updating mongo tools.
I am trying to run mongorestore.exe from a DB dump files of collections into DocumentDB database. I have experience with MongoDB and Azure but not much with DocumentDB.
I am getting an error
error parsing command line options: unknown option "ssl"
if I use the command from this tutorial.
I have locally installed MongoDB Community Server, "Windows Server 2008 R2 64-bit and later, with SSL support x64" of the latest stable version - 3.2.4.
It looks like the the --ssl command might not be available since the version 3 (link).
However SSL is enforced by DocumentDB.
Any idea how to migrate an existing database from MongoDB to DocumentDB?The DB is quite large (~GB), hence mongoimport would take too long, we need to user mongorestore, I believe.
Updated, command example:
mongorestore.exe --host myhost123.documents.azure.com:10250 -u myhost123 -p somepassword== --db myhost123 --ssl --sslAllowInvalidCertificates
gives me this error:
error parsing command line options: unknown option "ssl"
If I remove the two ssl options (--ssl --sslAllowInvalidCertificates) I get back an error which kind of makes sense as SSL is enforced on Azure DocumentDB:
Failed: error connecting to db server: no reachable servers
According to your description, I installed MongoDB Community Server Windows Server 2008 R2 64-bit and later, with SSL support x64 -3.4.3 and followed this official tutorial about importing data to API for MongoDB with mongorestore. After some trials, I could restore my local file generated by mongodump to my Azure DocumentDB (MongoDB API) as follows:
Failed: error connecting to db server: no reachable servers
I also encountered this error, and found that it was caused by IP Access Control,
my current IP is not included as the allowed list of client IP addresses. You could find more details about DocumentDB firewall here.
I'm trying to connect to a remote MongoDB v3.0.8 hosted in MongoLab using a Fantom v1.0.67 script. The driver I'm using is afMongo v1.0.4. The connection line is:
mongoClient := MongoClient(
ActorPool(),
`mongodb://mydbuser:mydbpassword#ds0#####.mongolab.com:#####/mymongodb`
)
Please note that the placeholders mydbuser, mydbpassword and ##### are replaced with the correct values. The connection is successful when I run the following command from a shell:
mongo ds0#####.mongolab.com:#####/mymongodb -u mydbuser -p mydbpassword
but from the Fantom script, I get this error:
afMongo::MongoCmdErr: Command 'authenticate' failed. MongoDB says: auth failed
afMongo::Operation.runCommand (Operation.fan:36)
afMongo::Operation.runCommand (Operation.fan)
afMongo::Connection$.authenticate (Connection.fan:34)
afMongo::TcpConnection.authenticate (Connection.fan:51)
afMongo::ConnectionManagerPooled.checkOut (ConnectionManagerPooled.fan:458)
afMongo::ConnectionManagerPooled.leaseConnection (ConnectionManagerPooled.fan:320)
afMongo::Cmd.run (Cmd.fan:71)
afMongo::Database.runCmd (Database.fan:36)
afMongo::MongoClient.runAdminCmd (MongoClient.fan:107)
afMongo::MongoClient.buildInfo (MongoClient.fan:64)
afMongo::MongoClient.startup (MongoClient.fan:119)
afMongo::MongoClient.makeFromUri$ (MongoClient.fan:41)
afMongo::MongoClient.makeFromUri$ (MongoClient.fan)
afMongo::MongoClient.makeFromUri (MongoClient.fan:38)
I have also tried Robomongo v0.8.4 with a similar result: A pop-up dialog saying...
Successfully connected to ds0#####.mongolab.com:#####
Authorization failed
I ran the Fantom script as well as Robomongo connecting and authenticating successfully against MongoDB v2.6.3 and v3.0.8 databases hosted locally.
My Java version is Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
I don't know if Robomongo or Fantom/afMongo depend on a Java or System library that is out of date.
What is wrong or what I should be checking, please?
The auth failures in both Robomongo v0.8.4 and afMongo 1.0.4 are due to a new authentication mechanism in MongoDB v3 called SCRAM-SHA-1.
afMongo has been updated with an implementation of SCRAM-SHA-1 over SASL. It auto detects Mongo v3 databases and switches the auth protocol, falling back to the older MONGODB-CR when needed - see this commit.
These changes haven't been released yet because it depends on a new method Buf.pbk(...) that is only available in Fantom 1.0.68 - which itself is unreleased. An updated afMongo v1.0.6 will be released as soon as Fantom 1.0.68 is.
You could compile Fantom 1.0.68 and afMongo 1.0.6 from source, but to be honest, the easiest fix (in the meantime) is to just use a v2.6 MongoDB database.
Note that, if needed, the MongoChef GUI client can authenticate against MongoDB v3 databases.
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/
We have an old MongoDb 2.2.6 deployment and lately we were requested to introduce anonymous user blocking to the Db. I followed the MongoDb tutorials and created an authentication user first and started the mongod with
--auth
parameter.
Then after login, I could not execute any db related commands except for the
use << db >>
. Everything was perfect. But then I tried issuing
use <<< some_junk_db_name >>
without authentication and then issued
db.some_collection.find()
command. Mongodb correctly raised an exception but later when I checked, that DB was there.
Is this a bug with MongoDb 2.2.6 or am I missing something here ?
This is a reported Bug with the number 2080 and the ticket is still not fixed. The last comment, May 17 2013, from a MongoDB Inc. member says that the Bug is still existing in the 2.4 version of MongoDB.
In Version 3.4 the Bug was no longer reproducable.