views:

62

answers:

2

Consider the following setup:

There a 2 physical servers which are set up as a regular mongodb replication set (including an arbiter process, so automatic failover will work correctly).

now, as far as i understand, most actual work will be done on the primary server, while the slave will mostly just do work to keep its dataset in sync.

Would it be reasonable, to introduce sharding into this setup in a way that one would set up another replication set on the same 2 servers, so that each of them has one mongod process running as primary and one process running as secondary.

The expected result would be that both servers will share the workload of actual querys/inserts while both are up. In the case of one server failing the whole setup should elegantly fail over to continue running, until the other server is restored.

Are there any downsides to this setup, except the overall overhead in setup and number of processes (mongos/configservers/arbiters)?

+1  A: 

That would definitely work. I'd asked a question in the #mongodb IRC channel a bit ago as to whether or not it was a bad idea to run multiple mongod processes on a single machine. The answer was "as long as you have the RAM/CPU/bandwidth, go nuts".

It's worth noting that if you're looking for high-performance reads, and don't mind writes being a bit slower, you could:

  • Do your writes in "safe mode", where the write doesn't return until it's been propagated to N servers (in this case, where N is the number of servers in the replica set, so all of them)
  • Set the driver-appropriate flag in your connection code to allow reading from slaves.

This would get you a clustered setup similar to MySQL - write once on the master, but any of the slaves is eligible for a read. In a circumstance where you have many more reads than writes (say, an order of magnitude), this may be higher performance, but I don't know how it'd behave when a node goes down (since writes may stall trying to write to 3 nodes, but only 2 are up, etc - that would need testing).

Chris Heald
A: 

I am sorry, but you miss one crucial detail: if you have a sharded setup with two pysical nodes only, if one dies, all your data is gone. This is because you don't have any redundancy below the sharding layer (the recommended way is that each shard is composed of a replica set).

What you said about the replica set however is true: you can run it on two shared-nothing nodes and have an additional arbiter. However, the recommended setup would be 3 nodes: one primary and two secondaries. http://www.markus-gattol.name/ws/mongodb.html#do_i_need_an_arbiter

Markus Gattol
the idea is, to have the 2 servers replicate to eachother. So server 1 is the master of shard1 and the slave of shard2. In case of a server failure, the remaining server will become master of both shards.
MGriesbach