Details
-
Task
-
Status: Closed
-
Major - P3
-
Resolution: Fixed
-
None
Description
----------------------------
Original Description
Description:
When a mongod is started with --repair and data or metadata is modified by the operation, the instance will be unable to rejoin its original replica set without a full resync. The only way to add the instance back to a replica set would be to delete the local.system.replset collection or wipe the data directory entirely.
Additionally, if a repair operation fails to complete for any reason, the instance will not be able to start again without the --repair option.
Engineering Ticket Description:
When MongoDB is started with --repair, the repair process will attempt to salvage data at the expense of potential data loss so that MongoDB can be started normally.
If a user is unaware they have lost data, they may attempt to add the node back to its original replica set. In the worst-case scenario, this node will become primary and data will appear to go missing.
There are currently no measures in place to prevent a secondary with data modified offline from re-joining its original replica set (even without repair).
Solution: If repair modifies collections (not indexes), repair will add a top-level field "repaired: true" to the local.system.replset configuration document. This will invalidate the document and prevent the node from re-joining as a member of the replica set. When the server starts up again normally, a warning will be printed with instructions for performing a re-sync.
----------------------------
Description
Scope of changes (files that need work and how much)
Impact to other docs outside of this product
MVP (work and date?)
Resources (e.g. Scope Docs, Invision)
Attachments
Issue Links
- documents
-
SERVER-35731 Prevent a repaired node from re-joining a replica set
-
- Closed
-