Tag Info

New answers tagged

0

I am doing the same thing and it is slow as well. I use hashed as shard key and it moves ~360MB size of data in 14 minutes. It means if I am moving 500GB worth of data, it will takes 13 days! I don't know whether it is normal or not, but I'm using default configurations on m3 medium AWS machines.


2

i have used PostGIS for over a decade now and I can tell you for sure that there is no match for it in the NoSQL world. how many rows do you have? how large is the thing? Mongo is definitely not going to make you happy. I am pretty sure you did something fishy on the PostgreSQL side to even consider using Mongo. Let us fix it ...


-1

there is absolutely nothing special about it. absolutely zero; nothing. if you want REALLY advanced indexing -> use PostgreSQL.


1

PostgreSQL is perfectly fine for this. You got a couple of options to make this work. First of all: PostgreSQL has a special index type for that called GIN (http://www.cybertec.at/gin-just-an-index-type/). It is perfect for full-text-search in general. The cool thing is: In the latest version of PostgreSQL there is support for a thing called jsonb. You ...


1

You may want to have a look on that document http://docs.mongodb.org/manual/reference/database-references/ . In general join is not a good practice for mongodb since it does not automatically supported. You might need to nest some author attributes - if not all information - that commonly used by your find queries on the blog collection for faster lookup.


0

If you are using MongoDB Enterprise version 2.6+, auditing will record the dropDatabase audit event in the audit log.


0

The answer to my question comes from an article I found this afternoon and I completely understand what I was doing wrong before. http://demarcsek92.blogspot.com/2014/05/mongodb-ssl-setup.html I'll explain a little more because of the suggestion from Markus. Originally I was generating client and server key/certification pairs from a root CA that I had ...


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


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"


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


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



Top 50 recent answers are included