See this document for geographic distribution of replica-set members and
configuring read preferences in the Java driver:
1. Use secondaryPreferred reads for data that you don't need
up-to-the-second consistency for. The Java driver will, by default, read
from the member with the shortest ping time, plus member within 15ms of
that shortest ping-time, so you most likely *won't* need to futz with
tagging to read from RS members in the correct data-center.
2. Put an equal number of members of each replica set in each data center
(e.g., three members in each)
3. Put an arbiter for each RS outside of any data center, e.g. on a cloud
server. Thus if you lose one data center or the other, the members in the
surviving DC plus the arbiter form a majority of the original RS. Now we're
describing 7-member RSes: 3 data members in each DC, plus an arbiter
4. If you have three members of each RS in each DC, then even if you lose a
DC, you'll continue to have a primary and two secondaries.