[SERVER-39034] Disallow CRUD ops against replica set members in standalone mode, with a server parameter override that prevents re-introduction of the node into the replica set Created: 16/Jan/19  Updated: 06/Dec/22  Resolved: 08/Feb/19

Status: Closed
Project: Core Server
Component/s: Replication, Storage
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Dianna Hohensee (Inactive) Assignee: Backlog - Storage Execution Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Storage Execution
Participants:

 Description   

Replica set members in standalone mode will no longer be allowed to take user writes. Metadata operations will continue to be allowed. The user can override this default with a new server parameter, which will also set an existing flag that will prevent the re-introduction of the node back into its replica set. So writes will be allowed again, but they will cause the node's data to diverge from the replica set, and would cause data inconsistencies if allowed to rejoin the replica set, so we won't allow it anymore.

The new server parameter should cause the index builds found on startup to be dropped, just like a non-repl member in standalone mode does on startup, since retaining them is only important for re-introduction to the replica set.



 Comments   
Comment by Dianna Hohensee (Inactive) [ 08/Feb/19 ]

Closing as Won't Fix. We've decided that this behavior is not aggravated by the simultaneous index builds project, so it will not be addressed in the project.

Comment by Andy Schwerin [ 16/Jan/19 ]

Cool. Just make sure that there's a way to complete all of the supported restore processes for restoring nodes into existing and new replica sets.

Comment by Dianna Hohensee (Inactive) [ 16/Jan/19 ]

There's a flag in the local database, I believe introduced in the repair improvements project by Louis, that is currently tripped if repair actually makes repairs. Attempts to re-introduce the node to the replica set will then fail.

Comment by Andy Schwerin [ 16/Jan/19 ]

Also, have you designed the machinery for preventing rejoining the replica set?

Comment by Andy Schwerin [ 16/Jan/19 ]

The backup/restore process probably requires at least the ability to manipulate the local database.

Generated at Thu Feb 08 04:50:49 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.