(c) Stop the mongod process on the member. 

4. After re-configuring all members of the set, start each mongod instance in the normal way: use the usual port number and use the --replSet option. For example: 

mongod --dbpath /data/db1/ --port 27017 --replSet rs 

5. Connect to one of the mongod instances using the mongo shell. For example: 

mongo --port 27017 

6. To confirm the new configuration, call rs.conf() in the mongo shell. Your output should resemble: 

{ "_id" : "rs", "version" : 4, "members" : [ { "_id" : 0, "host" : "mongodb0.example.net:27017" }, { "_id" : 1, "host" : "mongodb1.example.net:27017" }, { "_id" : 2, "host" : "mongodb2.example.net:27017" } ] } 

## Configure a Secondary’s Sync Target 

## Overview 

Secondaries capture data from the primary member to maintain an up to date copy of the sets’ data. However, by default secondaries may automatically change their sync targets to secondary members based on changes in the ping time between members and the state of other members’ replication. See Replica Set Data Synchronization (page 594) and Manage Chained Replication (page 641) for more information. 

For some deployments, implementing a custom replication sync topology may be more effective than the default sync target selection logic. MongoDB provides the ability to specify a host to use as a sync target. 

To override the default sync target selection logic, you may manually configure a secondary member’s sync target to temporarily pull oplog entries. The following provide access to this functionality: 

• replSetSyncFrom command, or 

• rs.syncFrom() helper in the mongo shell 

## Considerations 

Sync Logic Only modify the default sync logic as needed, and always exercise caution. rs.syncFrom() will not affect an in-progress initial sync operation. To affect the sync target for the initial sync, run rs.syncFrom() operation before initial sync. 

