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.