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).
Related
I'm trying to export and import data from an old MongoDB database server to Azure CosmosDB with MongoDB API using mongodump and mongorestore. But i'm having issues with the connection to CosmosDB. I'm using a connection string with the URI flag.
My mongorestore command including connection string is the following:
mongorestore --uri="mongodb://$COSMOS_USERNAME:$COSMOS_PASSWORD#$COSMOS_HOST:$COSMOS_PORT/?maxIdleTimeMS=120000&retrywrites=false&appName=#$DB_NAME#&replicaSet=globaldb&ssl=true" --archive="$ARCHIVE_NAME"
The error message from the command is:
error restoring from archive 'testProdExport.archive': (BadValue) Retryable writes are not supported. Please disable retryable writes by specifying "retrywrites=false" in the connection string or an equivalent driver specific config.
As you can see in the connection string i'm including the retrywrites=false URI parameter, but it looks like CosmosDB doesn't recognize the parameter.
Does anyone have experience with something similar?
//Edit: I've tried and verified that the connection string is working in a mongoose connection as well as in MongoDB Compass.
I found that the various mongotools (mongoimport, mongorestore, etc.) seem to ignore the retrywrites=false or retryWrites=false in the URI, but tacking on the option --writeConcern="{w:0}" allows the command to run successfully on instances that don't support retryable writes
You can try a version of mongorestore that shipped with MongoDB 3.4. This may not be able to read recent dumps though.
The ismaster output you provided includes:
logicalSessionTimeoutMinutes: 30
This advertises session support but https://learn.microsoft.com/en-us/azure/cosmos-db/mongodb-feature-support-36 says cosmosdb does not support sessions.
CosmosDB is advertising support for a feature it does not implement, the tooling then (correctly) attempts to use it. This is a bug in cosmosdb.
On Windows, didn't have luck with appending on the connectionstring (not necessary if copied from Azure portal)
retryableWrite=false
nor --writeConcern w:0 switch
But I ended up trying all previous archives and the magic combination of mongo tools 100.0.0 worked on CosmosDB with MongoServer v3.6.
Attention: Please take care that this can lead to missing data in the collections you restored. Tested it multiple times with different versions of mongorestore. Use the version which is in the mongoserver archive with version 4.0.27. You don't need to provide writeConcern at all in this version. It will also display how many documents are restored instead of 0 in the newer versions.
This affects CosmosDb with API v4.0.
I have been running MongoDB on two Windows 10 PCs. However, one has mongo always running it seems where I only need to open command prompt and type mongo. This gives me access to the db on PC #1.
However, on PC #2, I must open command prompt and type mongod. Then I have to open a second command prompt to type in mongo, then I get access to the db on PC #2.
After doing this for about a year, I find I want to just want both PCs to work like PC #1, where I just type in mongo and not mongodb and only have to use one command prompt.
I checked online but there's nothing I found straightforward to accomplish this specifically.
Does anybody know the answer?
If in PC#2, your MongoDB version is < 4.0, then you can't do anything i.e., you have to continue with mongod to start Mongo as you do now.
But if your MongoDB version is >= 4.0 or you want to upgrade from lower version of MongoDB, you can follow the below steps.
Take backup of all databases with mongodump. If it is large volume data, then go through this.
Uninstall your MongoDB using Windows Uninstall Program features.
Reinstall MongoDB using the link.
While installing, ensure you select 'MongoDB Service' feature.
Start the MongoDB now in PC#2 as you do in PC#1.
Restore the old databases with mongorestore.
I am using mongodb 3.2.11 in Ubuntu Zesty 17.04 and I am connecting from Nodejs 4.6 to mongodb in HTTPS, the database server is bound to its own address (127.0.0.1) and I have created a user besides admin for read/write to the database.
Although, most of my tables were certainly dropped somehow, only users (empty) and sessions table were left.
I grepped my logs for "drop" with grep -r "drop" and got no results. Despite I am using very recent versions of the software and made some security measures they don't seem enough. At this time I don't need to recover the data, but I wanted to know what else should I be looking at?
Try to use "show collections" in the mongo shell in ubuntu and see if the collections are shown after doing "use dbnamehere".
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/
I have a rails-app which uses both mongoid and mongo. I use mongoid for my own models, and I use mongo because I have ruote with a ruote-mon storage.
In production however; I get
Mongo::ConnectionFailure: Failed to connect to a master node at localhost:27017
when I try to connect to the ruote storage. Even when I just do Mongo::MongoClient.new
Steps I have taken so far to try to resolve this:
I have made my mongodb an explicit master by setting master = true in /etc/mongod.conf
There are no $ENV variables set that could intervene with Mongo::MongoClient.new (double checked)
I have tried to connect using Mongo::MongoClient.new(:slave_ok => true) - same error
I have restarted my mongo database several times (w/o success).
I have checked my firewall settings and I can connect to localhost:27017 with telnet (as said, the mongoid documents can be fetched and stored w/o issue)
I am out of my wits... Any suggestions?
The reason this happened is because we were sending queries with meta operators ($query, $orderby, etc...) for the ismaster command during a connect. This command's output is used to determine whether you are connected to a primary or not and would fail because very old versions of mongodb don't support the use of meta operators.
This fix will be in version 1.8.2 of the gem but I strongly encourage anyone who is still running pre-1.8 versions of mongodb to upgrade. 2.0 is the current legacy release as of the time of this post and even 1.8 is no longer widely supported.
As jmettraux mentioned you can find more details about this on the MongoDB project Jira under Ruby-525
please look at: https://jira.mongodb.org/browse/RUBY-525
Should be fixed by the 1.8.2 mongo gem.