MongoDB Documentation, Release 3.0.4 However , if your MongoDB deployment uses TLS/SSL, MongoDB will encrypt all communication between replica set members. See Configure mongod and mongos for TLS/SSL (page 342) for more information. As with all MongoDB components, run arbiters in trusted network environments. The architecture of a replica set affects the set’s capacity and capability. This document provides strategies for replica set deployments and describes common architectures. The standard replica set deployment for production system is a three-member replica set. These sets provide re- dundancy and fault tolerance. Avoid complexity when possible, but let your application requirements dictate the architecture. Add members in a replica set according to these strategies. Deploy an Odd Number of Members An odd number of members ensures that the replica set is always able to elect a primary. If you have an even number of members, add an arbiter to get an odd number. Arbiters do not store a copy of the data and require fewer resources. As a result, you may run an arbiter on an application server or other shared process. Consider Fault Tolerance Fault tolerance for a replica set is the number of members that can become unavailable and still leave enough members in the set to elect a primary. In other words, it is the difference between the number of members in the set and the majority needed to elect a primary. Without a primary, a replica set cannot accept write operations. Fault tolerance is an effect of replica set size, but the relationship is not direct. See the following table: Chapter 9. Replication 572 9.2.2 Replica Set Deployment Architectures Strategies Determine the Number of Members Number of Members. Majority Required to Elect a New Primary. Fault Tolerance. 3 2 1 4 3 1 5 3 2 6 4 2