MongoDB Documentation, Release 3.0.4 Slaves asynchronously apply write operations from the master that the slaves poll from the master’s oplog . The oplog is finite in length, and if a slave is too far behind, a full resync will be necessary. To resync the slave, connect to a slave using the mongo and issue the resync command: use admin db.runCommand( { resync: 1 } ) This forces a full resync of all data (which will be very slow on a large database). You can achieve the same effect by stopping mongod on the slave, deleting the entire content of the dbPath on the slave, and restarting the mongod . Slaves cannot be “chained.” They must all connect to the master directly. If a slave attempts “slave from” another slave you will see the following line in the mongod long of the shell: assertion 13051 tailable cursor requested on non capped collection ns:local.oplog.$main Resyncing a Slave that is too Stale to Recover Slave Chaining Correcting a Slave’s Source Example The slave now polls data from the correct master . mongod --slave or mongod --slave --source prod.mississippi.example.net Restart the slave with the correct command line arguments or with no --source option. After configuring local.sources (page 654) the first time, the --source will have no subsequent effect. Therefore, both of the following invocations are correct: use local db.sources.update( { host : "prod.mississippi" }, { $set : { host : "prod.mississippi.example.net" } } ) 601 9.2. Replication Concepts To change a slave’s source, manually modify the slave’s local.sources (page 654) collection. Consider the following: If you accidentally set an incorrect hostname for the slave’s source , as in the following example: mongod --slave --source prod.mississippi You can correct this, by restarting the slave without the --slave and --source arguments: mongod Connect to this mongod instance using the mongo shell and update the local.sources (page 654) collection, with the following operation sequence: