MongoDB – Single Server/Instance Deployment Guide

In order :

1. There is one reason to have multiple mongod instances in one machine (other than machine efficient repset setups) and that one reason is the process wide write lock. If you run into a situation where you're bottlenecked by the write lock rather than any hardware resource bottleneck you can go for multiple mongod instances. In all other situations it's usually more practical to have one mongod process, especially given it's memory mapped based storage engine.
2. There's no ideal number. Adding shards (almost) linearly scales up write and read performance for sharded collections. It's a basic horizontal scaling solution and follows the rules for that sort of scaling.
3. Replica sets always consist of at least 3 members although 1 of them can be an arbiter (votes but does not replicate). If you add more you gain read performance if your application uses slaveOk flagged queries. Again, ideal number depends on your use case.
4. Depends. Most people use a hot backup scheme of some sort. There's no difference between MySQL backup conventions and MongoDB here.
5. Depends on whether or not you want to clone a single database or the entire cluster? Both are well documented.

The first part is the easiest answer - don't use master-slave, it has been deprecated for a couple of years at this point and will be removed in the future (once a few long standing limitations on replica sets are removed).

The second part, how to run with 2 nodes in a replica set is a bit more complicated. The simplest answer is don't, running one host with a data bearing node and an arbiter to get to 3 nodes is actually preferable. Consider these scenarios for a 2 node set:

• Host 1 down, Host 2 up. Result = no primary
• Host 1 up, Host 2 down. Result = no primary
• Host 1 up, Host 2 up. Result = healthy

Now, lets add an arbiter on Host 1 and see how that impacts things:

• Host 1 down, Host 2 up. Result = no primary
• Host 1 up, Host 2 down. Result = healthy
• Host 1 up, Host 2 up. Result = healthy

In fact, if you make the second node non-voting it's actually better than having it as a regular replica set node and gives you the same list of scenarios as having an arbiter on Host 1.

Strictly speaking, the answer to your question is that best practices suggest not to run with two nodes at all, since it actually makes the set more fragile from an operational perspective (though at least you have a copy of your data on another host for disaster recovery).

If you have to stick with 2 data bearing nodes, the best practice recommendation is to run an arbiter on one of the hosts, with the non-voting option as your alternative.