I have configured mongodb replicaset in aws using 3 ec2's with one primary and 2 secondary nodes. When I insert data on primary node it is getting synced to the secondary nodes which it should. But when I close the port via security group still the data is syncing to the secondary node whose port is closed even though the state in rs.status() in the primary node is stateStr" : "(not reachable/healthy)" -> for the secondary node(whose port is closed).

I tried this with my secondary node in different subnet public as well as private but its still getting synced.I am new to mongodb and might be doing something wrong. Could someone please suggest something.


Have you closed that path both ways...

If primary cannot "ping" secondary, it's not reachable/healthy, but if secondary can connect primary, it can replicate opLog...


As per MongoDB BOL Here

In order to maintain up-to-date copies of the shared data set, secondary members of a replica set sync or replicate data from other members. MongoDB uses two forms of data synchronization:

  1. Initial Sync

  2. Replication

Initial Sync

Initial sync copies all the data from one member of the replica set to another member. Even the initial sync to populate new members with the full data set, and replication to apply ongoing changes to the entire data set.

How the Process happened in Sync

When you perform an initial sync, MongoDB:

Clones all databases except the local database. To clone, the mongod scans every collection in each source database and inserts all data into its own copies of these collections. Changed in version 3.4: Initial sync builds all collection indexes as the documents are copied for each collection. In earlier versions of MongoDB, only the _id indexes are built during this stage.

Changed in version 3.4: Initial sync pulls newly added oplog records during the data copy. Ensure that the target member has enough disk space in the local database to temporarily store these oplog records for the duration of this data copy stage.

Applies all changes to the data set. Using the oplog from the source, the mongod updates its data set to reflect the current state of the replica set. When the initial sync finishes, the member transitions from STARTUP2 to SECONDARY.


Secondary members replicate data continuously after the initial sync. Secondary members copy the oplog from their sync from source and apply these operations in an asynchronous process.

Secondaries may automatically change their sync from source as needed based on changes in the ping time and state of other members’ replication.

Changed in version 3.2: MongoDB 3.2 replica set members with 1 vote cannot sync from members with 0 votes.

Secondaries avoid syncing from delayed members and hidden members.

If a secondary member has members[n].buildIndexes set to true, it can only sync from other members where buildIndexes is true. Members where buildIndexes is false can sync from any other member, barring other sync restrictions. buildIndexes is true by default.

For Your Further Ref Replica Set Oplog and Replica Set Deployment Architectures

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.