master-slave configuration

we consider to build test enviroment where mongodb will be configured as a slave to production db.

My question is: if it is going to be a slave then will it only get data from master db but will not send its updates?(this is what we actually need)

You want to send writes to the test database while synchronizing from the production database? Master-slave replication is replaced by replica sets for almost all use cases, but in neither paradigm will the slaves/secondary members accept writes, since that would cause an inconsistent state between the data in the different processes. If you want to synchronize the data continuously while sending writes to the test database, neither master-slave nor replica sets are appropriate. Can you clarify what exactly you need the test database to do so we can help you find an appropriate solution?

thanks for readiness to help. our need is to build test server where we can test our processes and for the sake that the test will be as real as possible, we want the db in the test enviroment to be identical to production although it continiously changes.

of cause we do not want production db to be influenced anyhow from testing enviroment.

is it possible? how can we acomplish it?

Will? any update?

I think the sensible option is to sync the test database to the production database at a particular point in time, either by adding the test server as a (hidden, priority 0) replica set member, syncing it, and then taking it of the replica set out, or by taking a backup of the production database and loading it into the test server. The latter option is faster than the former. You can simulate the updates to the production database by replaying the oplog of the production server against the test database while conducting tests - but you don't want to keep the test database as a member of the replica set because, as a secondary, it will not accept writes. This will allow your test database to mirror the data state of the production database but still allow you to do writes - except of course that writes you do for the test may interact with writes coming from the production system oplog and produce a different state.