-
Type:
New Feature
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Workload Scheduling
-
Fully Compatible
-
v8.1, v8.0
-
Workload Scheduling 2025-04-14, Workload Scheduling 2025-04-28
-
None
-
3
-
None
-
None
-
None
-
None
-
None
-
None
Currently, setUserWriteBlockMode server command is only used by mongosync. We want to expand its usage to scenarios where the file system is about to run out of space. For that, we need to ensure that the reason for blocking writes is visible and that different processes cannot disable each others' attempts to block writes.
The work tracked in this ticket will:
- modify the command to accept an optional reason-enum about why user writes are being blocked
- supported reasons will be DiskUseThresholdExceeded and MigrationInProgress
- specifying any other reason will result in an error
- store this reason-enum, if specified, on the GlobalUserWriteBlockState
- augment the error returned when a write is blocked by GlobalUserWriteBlockState::checkWritesAreaAllowed to contain a human-readable description of this reason
- expand the set of possible values for the serverStatus result field repl.userWriteBlockMode to include the DiskUseThresholdExceeded and MigrationInProgress cases
- add the repl.userWriteBlockModeCounters field to the serverStatus result and record it in FTDC
If setUserWriteBlockMode is already enabled with a different reason, the command will fail with an error indicating that writes are already blocked for another reason. The reason originally provided to enable write blocking must also be provided when disabling write blocking. If no reason or a different reason is provided than what was used when enabling write blocking, the command will fail with an error.
- is depended on by
-
COMPASS-9293 Investigate changes in SERVER-102961: Add reason to setUserWriteBlockMode
-
- Needs Triage
-