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
Related
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.
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.
My mongodb can't lanuch now, when I want start mongo got error ***aborting after invariant() failure
Now I want to restore collection-0-****.wt file to a new db, is this possible?
As at MongoDB 3.2, only full backups of WiredTiger data directories can be copied into a new instance. WiredTiger collection or index files aren't self-contained; they rely on other metadata in the WiredTiger.* catalog files. The invariant/assertion you are getting on startup is expected if data files are incomplete or inconsistent.
If you want to backup and restore a single collection, you should use mongodump and mongorestore, eg:
mongodump --db test --collection northwind --host host1
mongorestore --db test dump/test/northwind.bson --host host2
For supported full backup procedures, see: MongoDB Backup Methods.
I had the same issue and after spending 5 hours doing everything, found this.
https://medium.com/#imunscarred/repairing-mongodb-when-wiredtiger-wt-file-is-corrupted-9405978751b5
You will need to restore 1 collection at a time(a few at once when you get the hang of it), but it works!
I'm trying to restore a database with 100 collections (800GB) using mongorestore which was taken as a backup from mongo 2.4.4. I used the following command:
mongorestore -u <username> -p <password> -d bp_prod079
/data/backup/2015-11-28/bp_prod079 --batchSize=100
I'm using batchSize =1000, 500, 100 to try to make it work. I'm getting an insertion error after 10-15 collections. It almost runs for almost an hour and half perfectly when I get this error.
Failed: restore error: bp_prod079.ANEpisodeBreakdown: error restoring
from /data/backup/2015-11-28/bp_prod079/ANEpisodeBreakdown.bson:
insertion error: EOF
For me with a minor batchSize works. First I had --batchSize=50 and changed it to 10 --batchSize=10 and perfect.
On MongoDB servers using the WiredTiger storage engine (default on MongoDB v3.2.x), this error can also be thrown when running out of memory, causing both mongorestore and mongod to crash, as MongoDB developer #mpobrien explains here.
The solution is to add more RAM to the server, or tune the storage.wiredTiger.engineConfig.cacheSizeGB setting as described here:
https://groups.google.com/d/msg/mongodb-user/Ms2MXCajreg/OsW6ixcSCgAJ
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/