[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. |