MongoDB Documentation, Release 3.0.4 Change Hostnames in a Replica Set Overview See also: Assumptions { "_id" : "rs", "version" : 3, "members" : [ { "_id" : 0, "host" : "database0.example.com:27017" }, { "_id" : 1, "host" : "database1.example.com:27017" }, { "_id" : 2, "host" : "database2.example.com:27017" } ] } Chapter 9. Replication 642 Given a replica set with three members: And with the following rs.conf() output: • database0.example.com:27017 (the primary ) • database1.example.com:27017 • database2.example.com:27017 Replica Set Reconfiguration Process , Deploy a Replica Set (page 603), and Add Members to a Replica Set (page 616). If you use the first procedure, you must configure your applications to connect to the replica set at both the old and new locations, which often requires a restart and reconfiguration at the application layer and which may affect the availability of your applications. Re-configuring applications is beyond the scope of this document. This document provides two separate procedures for changing the hostnames in the host field. Use either of the following approaches: • Change hostnames without disrupting availability (page 643). This approach ensures your applications will always be able to read and write data to the replica set, but the approach can take a long time and may incur downtime at the application layer. • Stop all members running on the old hostnames at once (page 644). This approach has a shorter maintenance window, but the replica set will be unavailable during the operation. For most replica sets , the hostnames in the host field never change. However, if organizational needs change, you might need to migrate some or all host names. Note: Always use resolvable hostnames for the value of the host field in the replica set configuration to avoid confusion and complexity.