Question

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)?

Answer 1

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