Tag Info

New answers tagged

0

The lock spike coincides with a spike in page faults in MMS, which means that for that period of time (which looks pretty brief), there is data being paged in off disk (that is: not in memory). Since you mention that you are doing updates I would guess that something about the updates during that time frame is hitting a rarely used section of the data that ...


0

MongoDB makes good use of your RAM. As long there is free RAM, it will take it. It will first try to get the indices into RAM. You can see their size with use <yourDB> db.status() from the mongo shell. Next it will try to keep as much as possible of your working set in RAM (which is a bit simplified, but sufficient for this explanation). MongoDB ...


0

I haven't confirmed by looking at code but I'd bet they are updates to the local database regarding your secondaries. The primary keeps track of the current status of the secondaries in the set (including where they have synced to), so that would be an in-place update to the local.slaves collection. Similarly, there is local.replset.minvalid which will ...


2

I've been looking into reclaiming disk space this morning. I'd like to add that as of version 2.6 Mongo permits use of repairDatabase on the secondaries. So the process of recovery is to simply execute db.repairDatabase() on the offending databases.


0

I have correct this problem with the 2 parameters in the config file: net.http.enabled: "true" net.http.RESTInterfaceEnabled: "true"


1

Master/Slave replication is deprecated, will be removed in future versions and has no advantage over a replica set with two data bearing nodes and an arbiter (which is extremely cheap in terms of disk, CPU and RAM usage), safe for the fact that you don't need to run an arbiter. A replica set however offers automatic failover and some administrative ...


0

So assuming that node(n) is a physical box, and the host(n) is a mongod process...If the link between the nodes fails, nothing cool will happen :). node1 will continue operating as normal, and node2 will just sit there asking wtf. The regular secondary will only have 2/4 votes which is not the strict majority. If node1 fails, then you will have to ...


0

Generally it is not recommended to use IP addresses to configure a cluster. You have not mentioned your environment, but it is common for IP addresses to change in many environments with a reboot, or perhaps you will need to move one or more of the nodes to a different host in the future. Should that happen, your IP address will change but if you use ...


1

Just a shot in the dark. Could it be a problem with the primary servicing too many connectionss simultaneously? This information comes from the mongodb 202 training. If a primary can no longer service requests, there will be socket exceptions timeouts the over servers can no longer ping the primary possibly causing an election --maxConns limit ...


1

The answer as always is: it depends ;) With a bit of simplification: Indexes and recently read (and written) documents are kept in RAM until that RAM is needed for something else. So wether your data is read from RAM or from file pretty much depends wether RAM on the MongoDb node(s) is sufficient to keep the index and at least part of your data (called the ...


5

If the drop command ran slowly, then it will be recorded in the logs (by default >100ms), otherwise the only record of it will be in the oplog (assuming you are running a replica set, even a single node replica set) and that is assuming that it did not occur so far in the past that it has "fallen out" of the oplog (which is a capped collection). NOTE: ...


1

In this case, the following will happen: When a member rejoins the replica set, the point in time on which the oplog is identical on the cluster is figured out. If there are oplog entries beyond said given point in time, those entries are tried to be reverted and saved for human analysis. This is called a rollback in MongoLand. If the node was down for a ...


0

When Mongo 1 becomes available, it will be a secondary replica and should be sync to the primary (Mongo 2). If there is a conflict, the admin should decide to manually perform a rollback or not. See http://docs.mongodb.org/manual/core/replica-set-rollbacks/ It is recommended to use write concern when performing write operation to a MongoDB replica set ...


0

The easy, albeit a bit unsecure way Stop the first secondary Delete the content of it's dbpath Restart the secondary Wait for it to catch up with the primary Repeat process with the second secondary This is a bit unsecure as it is unknown why the secondaries entered the Recovering state. The more secure, but also more intrusive way As above, but stop ...


1

Remember, MongoDB has a dynamic schema. So it is perfectly ok to store this document: { "JobNumber" : "50001-01", "CustomerId" : "joe", "IdentifierNumber" : NumberLong(8812739), "TimesPrinted" : 0, "Packaging" : {"bundle":1200,"box":120,"pallet":3} } and this document { "JobNumber" : "50001-02", "CustomerId" : "jane", "IdentifierNumber" : ...


1

If you had multiple documents containing products, you could retrieve all as follows by capturing the query cursor and iterating over the set: replset:PRIMARY> var cur = db.Category.find( {}, {products:1} ); replset:PRIMARY> while (cur.hasNext()) { ... var doc = cur.next(); ... printjson(doc); ... } { "_id" : ObjectId("542450a928db034349fb3bf2"), ...


0

Your NoSql statment seems correct. You have only one embbeded documnent of products that's why you got only one. db.Category.find( {}, {products:1} ) Or you can use db.Category.find({products:1}) Don't get confuse with "products:1", it is a projection that you want products. Here Projection is of type { field1: <boolean>, field2: ...


1

The first part is the easiest answer - don't use master-slave, it has been deprecated for a couple of years at this point and will be removed in the future (once a few long standing limitations on replica sets are removed). The second part, how to run with 2 nodes in a replica set is a bit more complicated. The simplest answer is don't, running one host ...


0

You've given 'user' the readAnyDatabase permission. This means it has read access for every database in the cluster. Change the permission to readOnly so user will have read permission on admin DB only.



Top 50 recent answers are included