Tag Info

New answers tagged

0

I wouldn't suggest using capped collections: they scale badly, as they can't be sharded as of the time of this writing and maybe never. See the according feature request on MongoDB's JIRA. I would use a different approach. Use the users query string as _id. Since the exact query is what identifies your records, there is no need to hash it on the client ...


0

To answer your question, I start out with an empty collection csdbprotobuf.archive on a stand-alone server that has nothing currently in cache db.serverStatus({workingSet:1}) "workingSet" : { "note" : "thisIsAnEstimate", "pagesInMemory" : 10, "computationTimeMicros" : 4736, "overSeconds" : 81 }, Create the database and insert 10000 ...


0

I believe the issue you were experiencing here was SERVER-2592: fields in a document are reordered (sorted alphabetically) when setting a field value. As of the MongoDB 2.6 production release, the existing order of fields is now maintained on updates.


0

Migrating an existing sharded cluster to new hardware If you want to migrate a sharded cluster to new hardware, there is a tutorial in the MongoDB manual: Migrate a Sharded Cluster to Different Hardware Migrating data in an existing sharded cluster to a new cluster There is no officially supported process to migrate documents between two different MongoDB ...


0

Are there any benefits in disabling mongodb journaling besides performance gain? The only other marginal benefit is if you are using a 32-bit build (which is also not recommended for production use). Since 32-bit builds are limited to ~2Gb of addressable data for memory mapped files, the journal is off by default to allow for more data (with journal ...


0

There isn't enough information here to know if the "sync target falling more than 30s behind" was the case, but it seems likely if you are pushing through a lot of activity with all of your replica set nodes on the same machine. There should be some log entries confirming the change; if you're still on 2.6 you should be able to grep for: changing sync ...


1

If you want to migrate with minimal downtime, a straightforward approach would be to use MongoDB replication: Convert your current standalone node to a replica set by restarting your current mongod with a --replSet name and then running rs.initiate(). NOTE: The rs.initiate() step is a once off command that only needs to be run on a primary when the replica ...


1

To ensure there are no migrations in progress while taking your backup, you should stop the balancer via sh.stopBalancer(). Any in-progress migrations will be completed before the balancer is disabled. If you want to ensure the balancer is stopped before taking your backup, you can run the following in the mongo shell, which should return true: ...


0

If i have 10 shards, each being a 3 node replica set. If i loose 2 servers in a replica set causing the primary to change to a read-only secondary. Where does the mongos write new chunks to that the hash key would have sent to this shards primary? Each shard contains a subset of data for the sharded cluster. If the replica set backing a shard becomes ...


0

I've listed some alternatives for connection management below, in order of most to least recommended. Increase the connections allowed on the server The total incoming connection limit on the server is determined by the lesser of the limits imposed by the operating system or maxIncomingConnections (aka maxConns in MongoDB 2.4 and earlier). Typically Linux ...


1

To remove all fields (aside from _id), you can just update with an empty document: <?php $collection->update(array('name' => 'Amy'), array()); ?> That will update the document leaving only the _id field. Note that this won't free up any of the preallocated space for your capped collection.


0

I ended up using this command: mongo --quiet --eval "var c=new Mongo();var o=[];db.adminCommand('listDatabases').databases.forEach(function(d){o=o.concat(c.getDB(d.name).currentOp(true).inprog.filter(function(d){return d.op=='query';}).map(function(d){return d.query;}));});o" > cursor.json The expanded form of the actual js in there is var conn = new ...


0

Some notes on MaxTimeMS behaviour as at MongoDB 2.6: MaxTimeMS sets a cumulative time limit in milliseconds for processing operations on a cursor. Network latency and idle time for a cursor do not count toward MaxTimeMS. After the MaxTimeMS is reached, the operation will be killed at the next safe interrupt point (for example, when that operation yields). ...


1

MongoDB's dynamic schema supports different fields for documents within the same collection, so there is no strict requirement for all documents to have an active field. The main consideration here will be how that affects your application logic; it may be simpler to have an explicit field present and check the value. If you have an index on a field, ...


0

An easy way to achieve that is to use cron's @reboot feature: > crontab -e -u mongodb @reboot /usr/bin/mongod --configsvr --dbpath /data/configdb/ --port 21001 --logpath /var/log/mongodb/configsvr.log --fork @reboot /usr/bin/mongod --shardsvr --dbpath /data/db/ --port 31001 --logpath /var/log/mongodb/mongod.log --fork However, you have to make sure ...


0

Actually, it is a Very Bad Idea™ to do a load balancing this way with MongoDB. First of all, you can give multiple mongos instances to the driver. If one mongos goes down or becomes unavailable due to overload, the driver will be happy to access the next available mongos. Second, the config servers and mongod instances get unnecessary load for continuously ...


0

It is not possible per request, but you might want to give the free MMS a try, which has quite some metrics. Together with the hardware monitoring provided by munin-node, you get a pretty good picture on what's going on on your MongoDB servers.


1

I had found this a while ago for the possibility of validating json data against a schema. If you wanted to do something like this, however, there's stuff you can do in javascript inside the database.


0

I had tried repairDatabase but as you mentioned it will not freeup the disk space. I would really want to free up the disk space. Is that something can be achievable?


1

The oplog is idempotent, you can run through the operations in it as many times as you want and you won't get duplicates or issues unless you run the operations on a set of data files in an odd state. However, it should be noted that as long as you have the journal as part of the LVM snapshot, re-running the oplog is not necessary for a consistent backup. ...


1

MongoDB is schemaless so it makes no sense to talk about a collection having fields and data types. You have to handle it in your own code if you want documents in a collection to have specific fields - MongoDB can't help you there.


0

All details are here: http://docs.mongodb.org/manual/release-notes/2.6-upgrade/ Answer 1: All metadata will get updated. I suggest to execute the mongos --upgrade using an extra mongos Answer 2: You don't have any downtime from the config servers since mongos have the require cached information and balancer is disable Answer 3: There is no other way. You ...


0

Adam has covered most of the points. However, there are a few things to add. Usage of Windows in a production environment For tl;dr candidates: It is a Very Bad Idea™ to run a mongod instance except for a config server on Windows. Here is why. Both ReFS and NTFS are at least 1/3 slower than ext4 or XFS, the recommended filesystems for Linux production ...


0

Expanding on Derek's answer: the last datafile preallocated will be unused. Always. As soon as the first document is written to a pristine data file, a new datafile will be allocated in parallel. This is done in order to prevent unnecessary latency when the existing data files don't have sufficient (free) space for a write operation. So at the expense of ...


0

The short answer: No No, you can't do so easily. The long answer: As always, it depends First: The reason for those data files to be created is simple: The mongod preallocates a new datafile as soon as the first document is written in the previously preallocated datafile in order to prevent unnecessary latency if when the space of a new datafile is ...


3

You can find these programs using the Linux find command as such: find / -name 'program_name' -print 2> /dev/null Where 'program_name' is for example, bsondump. find / -name 'bsondump' -print 2> /dev/null The 2> /dev/null prevents find from printing all the paths it looks at.


0

db.collection.getShardDistribution() That is a pretty good command I use often for stuff like this. It will show you total chunks, average chunk size, document counts, all on a per shard basis. It doesn't give you the data for each chunk like the answer above, but this is pretty quick and gives a good overview of what you're looking for.


1

Lot to go through here, so I'll take it piece by piece, first off splitting: I thought this meant that when a chunk hits 64mb, it splits into two equal chunks both of size 32mb. That's what is demonstrated here. Is that not correct? That's not quite how it works. If you have a 64MB chunk and you manually run a splitFind command, you will get (by ...


0

The issue was only one replica-set was being monitored by the MMS and second one was not. The issue is resolved now. The problem was the corresponding nodes of these replica-sets were given more than one host names in /etc/hosts file and out of them one host name was common between them which was also their default host name given in /etc/hostname file. This ...


0

From the MMS Dashboard; what is the MMS Agent Log saying? Have you looked in the mms-monitoring agent log locally on the server? /var/log/mongodb-mms/monitoring-agent.log Update Please add a screen shot of how you are configuring the host Update 14:02 Can you ping S143, S144 and mongo-client2 from the server where the mms-agent is installed? Can ...


1

You really only have 2 choices when a primary is still processing deletes from previous migrations (which is why you are getting the failure to engage error): Wait for the deletes to finish Step down the primary of that shard (assuming it is a replica set) The first action may take a long time if the shard in question is under heavy load, but it is the ...


0

There is no inconsistency here, this is simply due to how you have the volumes mounted and where you have located you MongoDB database path. You have one logical volume mounted on root (/) and the other mounted on /home - I am guessing you do not have your database path in MongoDB set to something under /home instead it is set to something else which is ...



Top 50 recent answers are included