Tag Info

Hot answers tagged

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: ...


2

You are missing a node, either another data bearing node or an arbiter. Here is why. A replica set needs a quorum > 50% of the original replica set members. Additionally, if a single node could decide to become primary, every network partitioning, every failing switch would result in a split brain situation, where two nodes assume they are primary. Add an ...


2

Yes, you can simply stop one config server, upgrade and restart it. That is one of the reasons why there are three: even when taking down one, there are two others to read from, so one might fail. A few things to keep in mind, though: When one config server is down, the cluster meta data is read only: no chunk splits or migrations during that time. So in ...


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.


2

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 ...


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 ...


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 ...


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"), ...


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 ...



Only top voted, non community-wiki answers of a minimum length are eligible