New member _id for resync replica


From documentation, the final step for resync replica is to start mongod with a new members[n]._id . But how? I don’t see mongod command provides such an option?

I’m struggling to decipher that too. I encourage you to use the page feedback feature on that page.

I don’t see anything in the release notes to justify the changes from 4.4 but I also have not tried this on the 5.0 version yet.

Hello @Lin_Yuan
would be great when you please could add your findings when there are some, beside Chris and me :slight_smile: there might be others who are interested to know.

Tried the 4.4 style seeding with 5.0, works the same. I will also supply some documentation feedback.

Hi @Lin_Yuan welcome to the community!

The reason for the change in the documentation (vs. 4.4) is the possibility of a corner case discovered in SERVER-47852. The scenario is a bit complicated, but the gist is that an unfortunate combination of network partition and resync happening at the same time could lead to loss of majority acknowledged write.

This led to SERVER-47363. Since MongoDB uses the replica set’s member _id to identify a unique member, reusing this _id could lead to undesirable outcomes, since at that point MongoDB couldn’t figure out if this is a legit member rejoining the set after maintenance/network partition or is this a new member being resynced. Resyncing by removing the dbpath of an existing member basically is reusing the _id for a “new” member, so it’s not the recommended approach anymore.

Therefore the updated documentation is saying that if you want to resync an existing member (e.g. due to it fallen off the oplog), then the best method is to do a remove and re-add using a different _id. This can be done using rs.reconfig(). To faciliate this, SERVER-48345 removes the limitation that _id must be lower than 255.

I realize that this is a bit confusing and complex. However there are internal efforts to streamline this process in future MongoDB versions.

Best regards,


@kevinadi IMO the documentation is inadequate, it leaves the reader hanging, no references to removing the member and adding it with rs.reconfig().

Imagine giving that tutorial verbatim in MongoDB University and measuring the success rate.

1 Like

Hi @chris , that’s a good point. I submitted DOCS-14720 for the documentation team to follow up, based on the discussion in this thread. Thanks!

Best regards


This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.