CODEWITHSUNDEEP
mongodbreplicationsystem-administrationsharding
MGriesbach
MGriesbach

Reputation: 354

mongoDB replication+sharding on 2 servers reasonable?

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

Upvotes: 8

Views: 3741

Answers (4)

Ben McCann
Ben McCann

Reputation: 19004

One thing to note is that while both machines are up, your queries are being split between them. When one goes down, all queries will go to the remaining machine thus doubling the demands placed on it. You'd have to make sure your machines could withstand a sudden doubling of queries.

Upvotes: 1

evdama
evdama

Reputation: 2206

You are missing one crucial detail: if you have a sharded setup with two physical 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

Upvotes: 0

Andrew
Andrew

Reputation: 1616

In that situation, I'd reconsider sharding in the first place, and just make it an un-sharded replica set of 2 machines (+1 arbiter).

Upvotes: 0

Chris Heald
Chris Heald

Reputation: 62648

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

Upvotes: 10

Related Questions