New answers tagged

0

Documents that cannot be dumped are broken in some way or the other. Either they reached the 16MB size limit, contain Null-Strings or other problematic stuff. You have to break down your dump into steps. If I were in your shoes, my preferred strategy would be to make an Update on the document set, assuming that you cannot update what you cannot dump. db....


2

I'm not sure if you're using cursors on your client side but due to your long query, you could be hitting a internal timeout of 10 minutes. If you do check out Jira Ticket SERVER-3090 on Mongo. If you are not using cursors then you can look at changing the _waitForDelete option in the balancers so the primary waits for the replicas to process the delete ...


0

1) All members of a replica have roughly equivalent write traffic; as a result, secondaries will service reads at roughly the same rate as the primary. By definition, all data-bearing members of a replica set maintain the same data set so the write traffic is roughly similar for secondaries - but not necessarily identical if compared to a primary. ...


1

You'll need to rethink your shard key approach. As at MongoDB 3.2: All fields in a compound shard key must be present in all documents and will be immutable (i.e. the shard key for an existing document cannot be changed). A hashed shard key is based on a single field, and does not support range queries. It generally makes sense to have a shard key that ...


0

So after a lot of struggle and a lot of load testing, we solved the problem by upgrading PyMongo to 2.8.1. PyMongo 2.7.2 is the first version to support MongoDB 2.6 and it sure does have some problems handling connections. Upgrading to PyMongo 2.8.1 helped us resolve the issue. With the same load, the connections do not exceed 250-300.


1

You mention the smallfiles option (from ObjectRocket docs) but your ls output suggests that you are not actually using it. If you were, then your maximum file size would be 512MB but you have 2GB files (the default). It also explains your issues. As soon as you fill up your existing data files and another write comes in (it's a little more complicated ...


1

I'd recommend looking into pre-splitting and/or using a hashed shard key to do the insertion and stick with dropping the collection (with remove you are basically doing a delete for every write, so it will always be slow). The hashed shard key is usually the easiest one to get started with. If you are looking to measure write throughput then each of those ...


1

Switching a primary in a replica set to a standalone will not impact CPU unless you were offloading something to the secondaries that will now hit the standalone node like reads or Map Reduce (and you mention you were not). As well as that, mongod is generally not CPU intensive unless you are doing lots of sorts or distincts (or a lot of javascript, Map ...


2

A graph database would be a good candidate. They specialise at retrieving interconnected data and navigating the relationships between objects. The ones I'm familiar with allow dynamic schema so different objects can have different values. Some allow classes of objects to be constructed so some consistency can be enforced. The links between objects are ...


0

Having mongo as a replica set allows for: (this things will be unavailable in single instance) Overcome failure of a master system (with low latency) have data distributed (in two/three different data centres) Split load and allow to query secondaries Overcome network segmentation issues When you switch to one instance - whatever will stop the only ...


-1

STARTUP2 state could be due to not enough disc space. Well, since there is no where to sync, it can only stay @ STARTUP2 state.


2

A configuration with three voting nodes in different data centres plus an additional non-voting delayed secondary is definitely supported. This is actually a reasonable configuration in terms of satisying core availability requirements using the distributed voting nodes with additional hidden/non-voting nodes for special use cases. A delayed secondary should ...


0

I had this same issue, and found out that I simply had the name of the replica set wrong in the addShard command.


1

Since you are using the MMAP storage engine there are several factors to be aware of: The compact command only defragments data files & indexes in MMAP; it does not release unused space to the operating system. Running compact can still be useful to reduce fragmentation and encourage free space reuse, but will not help if your disk space is critically ...


2

As at MongoDB 3.2, the only supported key for a sharded output collection for Map/Reduce is the _id field (non-hashed). There are known issues with Map/Reduce output to a sharded collection using a hashed shard index; the two features don't play well together yet and this isn't a supported combination. The documentation currently only suggests that _id can ...


0

It looks like findOne() is only deprecated in the Javascript driver. Its fine in the Shell Its fine in the C++ API Its fine in the C# API Its fine in the Java API Its fine in the Perl API Worse, MongoDB node driver uses findOne internally extensively. The change was made last year, as part of a series of commits carrying the helpful message "clean up ...


1

It looks like you are using NMAP as storage engine. From mongo 3.2 it was changed to WiredTiger as it is more efficient in space usage and allows to add compression - which in your case could be a plus. As NMAp reserves file storage using power of 2 and padding when storing documents - it is less disk storage effective and reservers lot more than is needed (...


1

The large number of nscanned key comparisons is explainable by the skip value: the query is skipping 903,462 documents (ntoskip) in order to return 21 (ntoreturn). The nscanned value in your output is the sum of ntoskip and ntoreturn. The number of nscannedObjects (identical to nscanned) is because the skip stage in MongoDB 2.6.x query processing happens ...


3

You can only use the $regex operator to match values that are strings. As you've noted, an ObjectID is a 12-byte binary value stored as a specific BSON type. You should instead use the $type operator to query based on the BSON data type of a field. Example usage of $type: // Find all restaurants where `_id` is not an ObjectId (type 7) db.restaurants.find({...



Top 50 recent answers are included