Four small, independent changes surfaced while running a manual
backup/restore demo end to end:
- fdbrestore now accepts -C and --cluster-file as aliases for
--dest-cluster-file. Every other tool (fdbcli, fdbbackup, fdbserver,
backup_agent) already pairs -C with --cluster-file; fdbrestore was
the lone outlier and forced scripts to special-case it.
- fdbcli now accepts --logdir as an alias for --log-dir. Every other
tool spells the flag --logdir (no hyphen); the --log-dir form in
fdbcli was the outlier here.
- fdbbackup status no longer prints "BulkLoad Compatible: no" when
Snapshot Mode is rangefile. In that mode the answer is tautologically
derivable from the line above it (no bulkdump task ever runs), so
the line carries no information. The field still prints in modes
bulkdump and both, where it can flip during an in-progress backup.
- Correct the misleading comment in FileBackupAgent.cpp that claimed
submitBulkLoadJob validates cluster preconditions server-side. It
does not. A bulkload restore against a cluster missing
shard_encode_location_metadata / enable_read_lock_on_range, or with
a storage engine that cannot ingest SSTs, succeeds at submission and
then silently stalls in "State: running, Tasks: 0/0" forever. Replace
the comment with a faithful description of the failure mode and add
a matching TODO in submitBulkLoadJob explaining where the real
validation needs to live (somewhere with cluster-side knob
visibility) and why it cannot be done from fdbclient.
* fdbcli: add rangelock command for range lock management
Wraps the existing range-lock management API (registerRangeLockOwner,
takeExclusiveReadLockOnRange, etc.) so SREs can inspect and release
locks left behind by failed bulkload jobs without writing a custom
client. Subcommands: register, unregister, owners, take, release,
release-all, list. The take subcommand prints a notice that locks
only take effect when knob_enable_read_lock_on_range is set on commit
proxies, since the client cannot probe server knobs.
* docs: document fdbcli rangelock command surface
Add a "Using fdbcli" subsection to documentation/sphinx/source/rangelock.rst
describing the new fdbcli command set introduced in this PR. Lists the seven
subcommands (register/unregister/owners/take/release/release-all/list),
flags the knob_enable_read_lock_on_range advisory that `rangelock take`
prints, and notes that the existing bulkload-specific commands remain in
place as a constrained subset.
Without this update, the doc continues to point readers at the C++
ManagementAPI as the only way to drive range locking, even though fdbcli
is now a faster path for operational use.
* docs: address PR review on bulkload subcommand prefixes
The bulkload-specific commands listed in the new "Using fdbcli"
subsection were written as `bulkload addlockowner / clearlock /
printlockowner`, which reads as if only the first carries the
`bulkload` prefix. In fdbcli all three are subcommands of `bulkload`
(see fdbcli/BulkLoadCommand.cpp lines 43, 45, 46), so the correct
user-visible form is `bulkload clearlock` and `bulkload printlockowner`
rather than the bare names.
Spell out the prefix on each command for clarity.
* fdbcli: address PR review on rangelock command
- Wrap every server-side rangelock call in try/catch and only print the
success message after the call succeeds. reportRangeLockError() maps
range_lock_reject / range_unlock_reject / range_lock_failed to
user-facing messages instead of letting raw FDB errors escape.
- Validate range bounds via normalKeys.contains(KeyRangeRef(begin, end))
in a new parseNormalKeyRange() helper, replacing the inline bound
arithmetic on take/release/list.
- Add empty-ownerId check on unregister/take/release/release-all,
matching the existing check on register.
- Clarify in RANGELOCK_LIST_USAGE that BEGIN_KEY and END_KEY must be
supplied together (or both omitted).
Prior efforts (PR#12435, PR#12470, PR#12486, PR#12583, PR#12667, PR#12903) removed some experimental features. This PR cleans up some leftover pieces.
I suppose this is basically a matter of historical interest at this point but those PRs were done purely by hand (ok, with like grep and a text editor) i.e. without any AI coding assistance. So it is not surprising that there is a few percent of leftover bits here and there.
Fixes:
Remove monitorBlobWorkers() and blobRestoreCommandActor() declarations that had no implementations (linker bombs if called)
Remove fast_restore from setclass help text (previously directed operators into an ASSERT(false) crash)
Dead knob removal (13 knobs):
12 blob worker ratekeeper knobs (BW_THROTTLING_ENABLED, TARGET_BW_LAG, etc.) and BLOB_WORKER_PAGE_CACHE
Remove bwLagTarget field from RatekeeperLimits and associated plumbing in Ratekeeper
Dead code removal:
4 never-incremented storage server counters (feedBytesFetched, changeFeedMutations, changeFeedMutationsDurable, changeFeedDiskReads)
Assigned-but-never-read nonExpanded variable in StorageServer::addMutation
ClusterNameRef/ClusterName typedefs, RestoreLoader/Applier/Master forward declarations
Dead schema strings (blob_worker_lag, blob_worker_missing, unreachable_blobManager_worker, metacluster_metrics_missing)
Dead cacheKeys*/cacheChange* function implementations in SystemData.cpp
Dead tenant group code in FuzzApiCorrectness.cpp
Dead fdbcli constants (msgClusterTypeKey, msgDataClustersKey) and blobrange history filter
Dead file removal:
contrib/mockkms/ -- unused Go mock KMS server
tests/fast/EncryptionUnitTests.toml -- tests a path (/blobCipher) that no longer exists
Trevor Clinkenbeard