If a log directory is specified in the "db_log_dir" option, RocksDB will add the whole file path in the log file name, which can exceed the 255 byte limit of Linux file system, causing storage server failures.
See
c3f720c60d/include/rocksdb/options.h (L674-L679)
* Allow multiple keyranges in CheckpointRequest.
Include DataMove ID in CheckpointMetaData.
* Use UID dataMoveId instead of Optional<UID>.
* Implemented ShardedRocks::checkpoint().
* Implementing createCheckpoint().
* Attempted to change getCheckpointMetaData*() for a single keyrange.
* Added getCheckpointMetaDataForRange.
* Minor fixes for NativeAPI.actor.cpp.
* Replace UID CheckpointMetaData::ssId with std::vector<UID>
CheckpointMetaData::src;
* Implemented getCheckpointMetaData() and completed checkpoint creation
and fetch in test.
* Refactoring CheckpointRequest and CheckpointMetaData
rename `dataMoveId` as `actionId` and make it Optional.
* Fixed ctor of CheckpointMetaData.
* Implemented ShardedRocksDB::restore().
* Tested checkpoint restore, and added range check for restore, so that
the target ranges can be a subset of the checkpoint ranges.
* Added test to partially restore a checkpoint.
* Refactor: added checkpointRestore().
* Sort ranges for comparison.
* Cleanups.
* Check restore ranges are empty; Add ranges in main thread.
* Resolved comments.
* Fixed GetCheckpointMetaData range check issue.
* Refactor CheckpointReader for CF checkpoint.
* Added CheckpointAsKeyValues as a parameter for newCheckpointReader.
* PhysicalShard::restoreKvs().
* Added `ranges` in fetchCheckpoint.
* Added RocksDBCheckpointKeyValues::ranges.
* Added ICheckpointIterator and implemented for RocksDBCheckpointReader.
* Refactored OpenAction for CheckpointReader, handled failure cases.
* Use RocksDBCheckpointIterator::end() in readRange.
* Set CheckpointReader timout and other Rocks read options.
* Implementing fetchCheckpointRange().
* Added more CheckpointReader tests.
* Cleanup.
* More cleanup.
* Resolved comments.
Co-authored-by: He Liu <heliu@apple.com>
* Allow multiple keyranges in CheckpointRequest.
Include DataMove ID in CheckpointMetaData.
* Use UID dataMoveId instead of Optional<UID>.
* Implemented ShardedRocks::checkpoint().
* Implementing createCheckpoint().
* Attempted to change getCheckpointMetaData*() for a single keyrange.
* Added getCheckpointMetaDataForRange.
* Minor fixes for NativeAPI.actor.cpp.
* Replace UID CheckpointMetaData::ssId with std::vector<UID>
CheckpointMetaData::src;
* Implemented getCheckpointMetaData() and completed checkpoint creation
and fetch in test.
* Refactoring CheckpointRequest and CheckpointMetaData
rename `dataMoveId` as `actionId` and make it Optional.
* Fixed ctor of CheckpointMetaData.
* Implemented ShardedRocksDB::restore().
* Tested checkpoint restore, and added range check for restore, so that
the target ranges can be a subset of the checkpoint ranges.
* Added test to partially restore a checkpoint.
* Refactor: added checkpointRestore().
* Sort ranges for comparison.
* Cleanups.
* Check restore ranges are empty; Add ranges in main thread.
* Resolved comments.
* Fixed GetCheckpointMetaData range check issue.
* Fixed error description.
Co-authored-by: He Liu <heliu@apple.com>
* Allow multiple keyranges in CheckpointRequest.
Include DataMove ID in CheckpointMetaData.
* Use UID dataMoveId instead of Optional<UID>.
Co-authored-by: He Liu <heliu@apple.com>
RocksDB supports injecting a custom logger. By introducing
RocksDBLogForwarder, it is possible to retrieve RocksDB log lines and
log them as TraceEvents.
Note that RocksDB is multi-threaded while FDB is designed to be
single threaded, in the FDB event loop there are certain variables
defined as thread_local. This causes that only FDB main thread could
generate TraceEvent, since information like Machine are only available
in the main thread. The current design is to cache all log lines from
the other threads, and let the main thread report the cached log, when:
* The main thread received log
* Every some time (this should be a Knob but at this stage a magic
number is used for convenience.)
It is possible to parse the log lines into Key/Value pairs for
TraceEvent output, but at this stage only the format string is printed
out. Also, RocksDB may log some errors that are interpreted as SevError,
which will cause simulation failures. To prevent this, the maximum error
level is set to SevWarn, which should be reconsidered carefully.
The code is tested by 1) random simulations to ensure the log lines are
included in the XML files 2) force the simulator uses RocksDB and run a
10k correctness run. Both tests passed.
* Store rocksdb::DBOptions and rocksdb::ColumnFamilyOptions to
SharedRocksDBState.
* Make KeyValueStoreRocksDBTest.toml `UNIT`.
* Added TEST_STORAGE_ENGINE_TYPE
* Added readOptions.
neethuhaneesha