Tag Info

New answers tagged

2

The first thing to look at is db.serverStatus().ft. This has a bunch of metrics that may be helpful, to figure out where you're spending time. These are documented here: http://docs.tokutek.com/tokumx/tokumx-server-status.html Usually the way to improve query time is to make sure you have the right index for your query. You might be doing a query on ...


0

OK, i think i know the answer. The OPLOG collection is a capped collection. It overwrites over time. The profile level was set to 2 for a short period of time logging all operations. I guess it will take time to overwrite these operations on a capped collection again and as a result increase the op log window. Would be interested in anyone elses take on ...


1

If you have the PEMKeyfile and CAFile set up correctly (per the docs) then the remaining piece of the puzzle is to run with requireSSL sslMode to make sure that you will only accept SSL connections for your databases (there are other modes to allow for mixing encrypted and non-encrypted clients, but that is only really recommended for upgrading from ...


0

In general, clustered-NoSQL databases offer you better horizontal scalability. So, as you scale you can get higher capacity (both memory & compute power) by simply adding new nodes. So, it will be a good insurance for the future. When it comes to ACID properties, NoSQL databases offer flexibility. So, it boils down to how much ACIDness you want and how ...


1

There is no need in having 2 arbiters. The minimum recommended replica set consists of THREE servers and is: a primary a secondary an arbiter the arbiter can be on either machines, but it is recommended to be on a separate machine (VM or anything) so that it won't go down with one of the servers if something goes wrong. You could use multiple arbiters ...


0

The default stack size for MongoDB is already 1024, not 8192 (it is set in the code, not as a system setting) and has been since version 1.8.3 (see SERVER-2707), so you are already seeing the benefits of a lower stack size.


2

The problem explained As per your comment, your shard key is the _id field of the document. This field is monotonically increasing, basically like an incremented integer. Put simply, sharding works this way: documents are stored in chunks. Those chunks are spread over the cluster based on ranges of the shard key. Let's look at a simple example: s1: ...


0

You haven't mentioned what driver you will be using, so I can't give you a direct link to the specific option in your language of choice, but yes there is an option to return partial results from a sharded cluster if there are shards down (I still don't advocate running without replica sets, but that's a different discussion). You can set it in the shell as ...


0

Actually, it is pretty easy to configure a delayed member of a replica set via the shell: cfg = rs.conf() cfg.members[0].priority = 0 cfg.members[0].hidden = true cfg.members[0].slaveDelay = 3600 rs.reconfig(cfg) In this example taken from the docs, the first member of replica set will be reconfigured to have a delay of one hour. Note that this delayed ...


1

The page faults metric for MongoDB on Windows essentially contains hard (actually hitting disk) and soft (reallocating a pointer in memory) page faults. If you run the same experiment on Linux, the page fault metric only reports hard page faults and you will see the behavior you expect. This is a known issue with the Windows version and the relevant issue ...


0

In each database, there is no one answer to what size something is when it is stored. In MongoDB there are several factors to take into account, for example: What types are being stored (BSON having more types than JSON, and with each getting different allocations) Should you include the (16 byte) record header? Is the collection you are storing the data ...


1

Basically you have a few misunderstandings here, the first being that the balancer is a load balancer. It is not - it simply looks to address imbalances in chunk counts on your shards. That can have the side effect of balancing your traffic out as it moves chunks around, but strictly speaking it is not a load balancer. It also does not run continuously, ...


0

MongoDB Docs: Enables or disables the balancer. Use sh.getBalancerState() to determine if the balancer is currently enabled or disabled and sh.isBalancerRunning() to check its current state. Sharded Collection Balancing: http://docs.mongodb.org/manual/core/sharding-balancing/ But your question should go in dba.stackexchange.com


0

There is a 10 minute time out for inactive cursors, and it can be overridden, but be careful: "immortal" cursors can become a problem if enough of them accumulate on the server over time. So, it would be a good idea to close your cursor correctly from time to time and avoid that if possible. You should also make sure that it is in fact the cursor timeout ...


2

Back in the day we would bulk load our data in this way: Drop indexes Load data in the order for which the clustered index would be built (i.e., you export the data in a precise way) After the load is completed, create the clustered index Next, create any additional non-clustered indexes Miller time (this was before I could afford decent beer) That ...


0

You have few options here. Run DB command 'Compact' on the collection - This will not reclaim disk space, but will perform defragmentation over the specific collection. Perform a repairDatabase - This reclaims disk space back to the OS. the repairDatabase runs over the entire DB (or shard) and not just one collection (I would read the documentation, as ...


1

If you are doing a large, load operation it is faster to utilize the TokuMX bulk loader, as it only requires one pass over the data to create both the primary key index and any secondary indexes. More information is available in the documentation at http://docs.tokutek.com/tokumx/tokumx-commands.html#tokumx-new-commands-loader


1

I do not understand why the failover to DC2 has to be done manually (even if other parts have to be done manually: one thing less on your to do list in case of a major failure is always a good thing!). In general, my feeling is that there are conceptual flaws in your setup. Here is how I would do it and why. I would not have manual failover. It is better ...


0

With a single node i don't think you have other option than mongodump and LVM snapshot. In the case you run on a replica set which is recommended for production you can just stop one secondary and copy the data directory.


0

I just know a workaround: manually resync the member of the replica set. Basically, it is done like this: Shutdown the mongod instance in question Delete the contents of the dbpath directory Restart the instance. It will sync then


0

Math first: you moved 150M documents in 2 days, which is roughly 860 documents per second including metadata and indices, where reading and writing all occurs on the same machine. That is not what I would call slow. The description coming to my mind is "lightning fast". ;) Since there is no real distribution of the write load, an easy way to speed things up ...



Top 50 recent answers are included