The architecture and design of the replica set deployment can have a great impact on the set’s capacity and capability. This section provides a general overview of best practices for replica set architectures.
This document provides an overview of the complete functionality of replica sets, which highlights the flexibility of the replica set and its configuration. However, for most production deployments a conventional 3-member replica set with members[n].priority values of1are sufficient.
- Ensure that the members of the replica set will always be able to elect a primary. Run an odd number of members or run an arbiter on one of your application servers if you have an even number of members.
- With geographically distributed members, know where the “quorum” of members will be in the case of any network partitions. Attempt to ensure that the set can elect a primary among the members in the primary data center.
- Consider including a hidden or delayed member in your replica set to support dedicated functionality, like backups, reporting, and testing.
- Consider keeping one or two members of the set in an off-site data center, but make sure to configure the priority to prevent it from becoming primary.