2016-09-23 23:34:04 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2017-07-15 23:03:42 +00:00
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
2016-09-23 23:34:04 +00:00
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
#include <string>
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
#include "rocksdb/options.h"
|
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2021-03-15 11:32:24 +00:00
|
|
|
class SystemClock;
|
2016-09-23 23:34:04 +00:00
|
|
|
|
|
|
|
struct ImmutableDBOptions {
|
2020-09-14 23:59:00 +00:00
|
|
|
static const char* kName() { return "ImmutableDBOptions"; }
|
2016-09-23 23:34:04 +00:00
|
|
|
ImmutableDBOptions();
|
|
|
|
explicit ImmutableDBOptions(const DBOptions& options);
|
|
|
|
|
|
|
|
void Dump(Logger* log) const;
|
|
|
|
|
|
|
|
bool create_if_missing;
|
|
|
|
bool create_missing_column_families;
|
|
|
|
bool error_if_exists;
|
|
|
|
bool paranoid_checks;
|
2021-05-20 23:06:12 +00:00
|
|
|
bool flush_verify_memtable_count;
|
2023-07-28 16:47:31 +00:00
|
|
|
bool compaction_verify_record_count;
|
2020-10-09 23:40:25 +00:00
|
|
|
bool track_and_verify_wals_in_manifest;
|
2022-05-19 18:04:21 +00:00
|
|
|
bool verify_sst_unique_id_in_manifest;
|
2016-09-23 23:34:04 +00:00
|
|
|
Env* env;
|
|
|
|
std::shared_ptr<RateLimiter> rate_limiter;
|
|
|
|
std::shared_ptr<SstFileManager> sst_file_manager;
|
|
|
|
std::shared_ptr<Logger> info_log;
|
|
|
|
InfoLogLevel info_log_level;
|
|
|
|
int max_file_opening_threads;
|
|
|
|
std::shared_ptr<Statistics> statistics;
|
|
|
|
bool use_fsync;
|
|
|
|
std::vector<DbPath> db_paths;
|
|
|
|
std::string db_log_dir;
|
2021-07-30 19:15:04 +00:00
|
|
|
// The wal_dir option from the file. To determine the
|
|
|
|
// directory in use, the GetWalDir or IsWalDirSameAsDBPath
|
|
|
|
// methods should be used instead of accessing this variable directly.
|
2016-09-23 23:34:04 +00:00
|
|
|
std::string wal_dir;
|
|
|
|
size_t max_log_file_size;
|
|
|
|
size_t log_file_time_to_roll;
|
|
|
|
size_t keep_log_file_num;
|
|
|
|
size_t recycle_log_file_num;
|
|
|
|
uint64_t max_manifest_file_size;
|
|
|
|
int table_cache_numshardbits;
|
2021-04-23 03:42:50 +00:00
|
|
|
uint64_t WAL_ttl_seconds;
|
|
|
|
uint64_t WAL_size_limit_MB;
|
2019-09-12 01:26:22 +00:00
|
|
|
uint64_t max_write_batch_group_size_bytes;
|
2016-09-23 23:34:04 +00:00
|
|
|
size_t manifest_preallocation_size;
|
|
|
|
bool allow_mmap_reads;
|
|
|
|
bool allow_mmap_writes;
|
2016-10-28 17:36:05 +00:00
|
|
|
bool use_direct_reads;
|
2017-04-13 20:07:33 +00:00
|
|
|
bool use_direct_io_for_flush_and_compaction;
|
2016-09-23 23:34:04 +00:00
|
|
|
bool allow_fallocate;
|
|
|
|
bool is_fd_close_on_exec;
|
|
|
|
bool advise_random_on_open;
|
|
|
|
size_t db_write_buffer_size;
|
|
|
|
std::shared_ptr<WriteBufferManager> write_buffer_manager;
|
|
|
|
size_t random_access_max_buffer_size;
|
|
|
|
bool use_adaptive_mutex;
|
|
|
|
std::vector<std::shared_ptr<EventListener>> listeners;
|
|
|
|
bool enable_thread_tracking;
|
2017-05-19 21:24:23 +00:00
|
|
|
bool enable_pipelined_write;
|
2019-05-14 00:43:47 +00:00
|
|
|
bool unordered_write;
|
2016-09-23 23:34:04 +00:00
|
|
|
bool allow_concurrent_memtable_write;
|
|
|
|
bool enable_write_thread_adaptive_yield;
|
|
|
|
uint64_t write_thread_max_yield_usec;
|
|
|
|
uint64_t write_thread_slow_yield_usec;
|
|
|
|
bool skip_stats_update_on_db_open;
|
Add an option to prevent DB::Open() from querying sizes of all sst files (#6353)
Summary:
When paranoid_checks is on, DBImpl::CheckConsistency() iterates over all sst files and calls Env::GetFileSize() for each of them. As far as I could understand, this is pretty arbitrary and doesn't affect correctness - if filesystem doesn't corrupt fsynced files, the file sizes will always match; if it does, it may as well corrupt contents as well as sizes, and rocksdb doesn't check contents on open.
If there are thousands of sst files, getting all their sizes takes a while. If, on top of that, Env is overridden to use some remote storage instead of local filesystem, it can be *really* slow and overload the remote storage service. This PR adds an option to not do GetFileSize(); instead it does GetChildren() for parent directory to check that all the expected sst files are at least present, but doesn't check their sizes.
We can't just disable paranoid_checks instead because paranoid_checks do a few other important things: make the DB read-only on write errors, print error messages on read errors, etc.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6353
Test Plan: ran the added sanity check unit test. Will try it out in a LogDevice test cluster where the GetFileSize() calls are causing a lot of trouble.
Differential Revision: D19656425
Pulled By: al13n321
fbshipit-source-id: c2c421b367633033760d1f56747bad206d1fbf82
2020-02-04 09:24:29 +00:00
|
|
|
bool skip_checking_sst_file_sizes_on_db_open;
|
2016-09-23 23:34:04 +00:00
|
|
|
WALRecoveryMode wal_recovery_mode;
|
|
|
|
bool allow_2pc;
|
|
|
|
std::shared_ptr<Cache> row_cache;
|
|
|
|
WalFilter* wal_filter;
|
|
|
|
bool fail_if_options_file_error;
|
|
|
|
bool dump_malloc_stats;
|
|
|
|
bool avoid_flush_during_recovery;
|
2017-05-17 18:32:26 +00:00
|
|
|
bool allow_ingest_behind;
|
2017-11-11 01:18:01 +00:00
|
|
|
bool two_write_queues;
|
2017-06-24 21:06:43 +00:00
|
|
|
bool manual_wal_flush;
|
2022-01-26 21:57:30 +00:00
|
|
|
CompressionType wal_compression;
|
Ensure Close() before LinkFile() for WALs in Checkpoint (#12734)
Summary:
POSIX semantics for LinkFile (hard links) allow linking a file
that is still being written two, with both the source and destination
showing any subsequent writes to the source. This may not be practical
semantics for some FileSystem implementations such as remote storage.
They might only link the flushed or sync-ed file contents at time of
LinkFile, or might even have undefined behavior if LinkFile is called on
a file still open for write (not yet "sealed"). This change builds on https://github.com/facebook/rocksdb/issues/12731
to bring more hygiene to our handling of WAL files in Checkpoint.
Specifically, we now Close WAL files as soon as they are either
(a) inactive and fully synced, or (b) inactive and obsolete (so maybe
never fully synced), rather than letting Close() happen in handling
obsolete files (maybe a background thread). This should not be a
performance issue as Close() should be trivial cost relative to other
IO ops, but just in case:
* We don't Close() while holding a mutex, to avoid blocking, and
* The old behavior is available with a new kill switch option
`background_close_inactive_wals`.
Stacked on https://github.com/facebook/rocksdb/issues/12731
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12734
Test Plan:
Extended existing unit test, especially adding a hygiene
check to FaultInjectionTestFS to detect LinkFile() on a file still open
for writes. FaultInjectionTestFS already has relevant tracking data, and
tests can opt out of the new check, as in a smoke test I have left for
the old, deprecated functionality `background_close_inactive_wals=true`.
Also ran lengthy blackbox_crash_test to ensure the hygiene check is OK
with the crash test. (The only place I can find we use LinkFile in
production is Checkpoint.)
Reviewed By: cbi42
Differential Revision: D58295284
Pulled By: pdillinger
fbshipit-source-id: 64d90ed8477e2366c19eaf9c4c5ad60b82cac5c6
2024-06-12 18:48:45 +00:00
|
|
|
bool background_close_inactive_wals;
|
2018-10-26 22:06:44 +00:00
|
|
|
bool atomic_flush;
|
2019-04-02 00:07:38 +00:00
|
|
|
bool avoid_unnecessary_blocking_io;
|
2019-06-17 22:17:43 +00:00
|
|
|
bool persist_stats_to_disk;
|
2019-09-03 15:50:47 +00:00
|
|
|
bool write_dbid_to_manifest;
|
2019-07-19 18:54:38 +00:00
|
|
|
size_t log_readahead_size;
|
2020-03-29 22:57:02 +00:00
|
|
|
std::shared_ptr<FileChecksumGenFactory> file_checksum_gen_factory;
|
2020-03-21 02:17:54 +00:00
|
|
|
bool best_efforts_recovery;
|
2020-07-15 18:02:44 +00:00
|
|
|
int max_bgerror_resume_count;
|
|
|
|
uint64_t bgerror_resume_retry_interval;
|
2020-09-30 06:16:12 +00:00
|
|
|
bool allow_data_in_errors;
|
2020-10-19 18:37:05 +00:00
|
|
|
std::string db_host_id;
|
2021-02-11 06:18:33 +00:00
|
|
|
FileTypeSet checksum_handoff_file_types;
|
2021-10-19 22:53:16 +00:00
|
|
|
CacheTier lowest_used_cache_tier;
|
2021-04-23 03:42:50 +00:00
|
|
|
// Convenience/Helper objects that are not part of the base DBOptions
|
|
|
|
std::shared_ptr<FileSystem> fs;
|
|
|
|
SystemClock* clock;
|
2021-04-26 19:43:02 +00:00
|
|
|
Statistics* stats;
|
|
|
|
Logger* logger;
|
2021-05-20 04:40:43 +00:00
|
|
|
std::shared_ptr<CompactionService> compaction_service;
|
2022-05-16 22:44:59 +00:00
|
|
|
bool enforce_single_del_contracts;
|
Basic RocksDB follower implementation (#12540)
Summary:
A basic implementation of RocksDB follower mode, which opens a remote database (referred to as leader) on a distributed file system by tailing its MANIFEST. It leverages the secondary instance mode, but is different in some key ways -
1. It has its own directory with links to the leader's database
2. Periodically refreshes itself
3. (Future) Snapshot support
4. (Future) Garbage collection of obsolete links
5. (Long term) Memtable replication
There are two main classes implementing this functionality - `DBImplFollower` and `OnDemandFileSystem`. The former is derived from `DBImplSecondary`. Similar to `DBImplSecondary`, it implements recovery and catch up through MANIFEST tailing using the `ReactiveVersionSet`, but does not consider logs. In a future PR, we will implement memtable replication, which will eliminate the need to catch up using logs. In addition, the recovery and catch-up tries to avoid directory listing as repeated metadata operations are expensive.
The second main piece is the `OnDemandFileSystem`, which plugs in as an `Env` for the follower instance and creates the illusion of the follower directory as a clone of the leader directory. It creates links to SSTs on first reference. When the follower tails the MANIFEST and attempts to create a new `Version`, it calls `VerifyFileMetadata` to verify the size of the file, and optionally the unique ID of the file. During this process, links are created which prevent the underlying files from getting deallocated even if the leader deletes the files.
TODOs: Deletion of obsolete links, snapshots, robust checking against misconfigurations, better observability etc.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12540
Reviewed By: jowlyzhang
Differential Revision: D56315718
Pulled By: anand1976
fbshipit-source-id: d19e1aca43a6af4000cb8622a718031b69ebd97b
2024-04-20 02:13:31 +00:00
|
|
|
uint64_t follower_refresh_catchup_period_ms;
|
|
|
|
uint64_t follower_catchup_retry_count;
|
|
|
|
uint64_t follower_catchup_retry_wait_ms;
|
2021-07-30 19:15:04 +00:00
|
|
|
|
|
|
|
bool IsWalDirSameAsDBPath() const;
|
|
|
|
bool IsWalDirSameAsDBPath(const std::string& path) const;
|
|
|
|
const std::string& GetWalDir() const;
|
|
|
|
const std::string& GetWalDir(const std::string& path) const;
|
2016-09-23 23:34:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct MutableDBOptions {
|
2020-09-14 23:59:00 +00:00
|
|
|
static const char* kName() { return "MutableDBOptions"; }
|
2016-10-14 19:25:39 +00:00
|
|
|
MutableDBOptions();
|
2016-09-23 23:34:04 +00:00
|
|
|
explicit MutableDBOptions(const DBOptions& options);
|
|
|
|
|
|
|
|
void Dump(Logger* log) const;
|
2016-10-14 19:25:39 +00:00
|
|
|
|
2017-05-24 18:25:38 +00:00
|
|
|
int max_background_jobs;
|
2016-10-14 19:25:39 +00:00
|
|
|
int max_background_compactions;
|
2020-07-23 01:31:25 +00:00
|
|
|
uint32_t max_subcompactions;
|
2016-11-02 22:22:13 +00:00
|
|
|
bool avoid_flush_during_shutdown;
|
2017-10-31 20:49:25 +00:00
|
|
|
size_t writable_file_max_buffer_size;
|
2016-11-12 23:43:33 +00:00
|
|
|
uint64_t delayed_write_rate;
|
2016-11-15 06:45:16 +00:00
|
|
|
uint64_t max_total_wal_size;
|
2016-12-05 22:09:35 +00:00
|
|
|
uint64_t delete_obsolete_files_period_micros;
|
2017-03-21 05:50:56 +00:00
|
|
|
unsigned int stats_dump_period_sec;
|
2019-02-20 23:46:59 +00:00
|
|
|
unsigned int stats_persist_period_sec;
|
|
|
|
size_t stats_history_buffer_size;
|
2017-05-04 03:46:17 +00:00
|
|
|
int max_open_files;
|
2017-09-28 00:37:08 +00:00
|
|
|
uint64_t bytes_per_sync;
|
|
|
|
uint64_t wal_bytes_per_sync;
|
Optionally wait on bytes_per_sync to smooth I/O (#5183)
Summary:
The existing implementation does not guarantee bytes reach disk every `bytes_per_sync` when writing SST files, or every `wal_bytes_per_sync` when writing WALs. This can cause confusing behavior for users who enable this feature to avoid large syncs during flush and compaction, but then end up hitting them anyways.
My understanding of the existing behavior is we used `sync_file_range` with `SYNC_FILE_RANGE_WRITE` to submit ranges for async writeback, such that we could continue processing the next range of bytes while that I/O is happening. I believe we can preserve that benefit while also limiting how far the processing can get ahead of the I/O, which prevents huge syncs from happening when the file finishes.
Consider this `sync_file_range` usage: `sync_file_range(fd_, 0, static_cast<off_t>(offset + nbytes), SYNC_FILE_RANGE_WAIT_BEFORE | SYNC_FILE_RANGE_WRITE)`. Expanding the range to start at 0 and adding the `SYNC_FILE_RANGE_WAIT_BEFORE` flag causes any pending writeback (like from a previous call to `sync_file_range`) to finish before it proceeds to submit the latest `nbytes` for writeback. The latest `nbytes` are still written back asynchronously, unless processing exceeds I/O speed, in which case the following `sync_file_range` will need to wait on it.
There is a second change in this PR to use `fdatasync` when `sync_file_range` is unavailable (determined statically) or has some known problem with the underlying filesystem (determined dynamically).
The above two changes only apply when the user enables a new option, `strict_bytes_per_sync`.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5183
Differential Revision: D14953553
Pulled By: siying
fbshipit-source-id: 445c3862e019fb7b470f9c7f314fc231b62706e9
2019-04-22 18:48:45 +00:00
|
|
|
bool strict_bytes_per_sync;
|
2017-11-17 01:46:43 +00:00
|
|
|
size_t compaction_readahead_size;
|
2020-04-20 23:17:25 +00:00
|
|
|
int max_background_flushes;
|
Offpeak in db option (#11893)
Summary:
RocksDB's primary function is to facilitate read and write operations. Compactions, while essential for minimizing read amplifications and optimizing storage, can sometimes compete with these primary tasks. Especially during periods of high read/write traffic, it's vital to ensure that primary operations receive priority, avoiding any potential disruptions or slowdowns. Conversely, during off-peak times when traffic is minimal, it's an opportune moment to tackle low-priority tasks like TTL based compactions, optimizing resource usage.
In this PR, we are incorporating the concept of off-peak time into RocksDB by introducing `daily_offpeak_time_utc` within the DBOptions. This setting is formatted as "HH:mm-HH:mm" where the first one before "-" is the start time and the second one is the end time, inclusive. It will be later used for resource optimization in subsequent PRs.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11893
Test Plan:
- New Unit Test Added - `DBOptionsTest::OffPeakTimes`
- Existing Unit Test Updated - `OptionsTest`, `OptionsSettableTest`
Reviewed By: pdillinger
Differential Revision: D49714553
Pulled By: jaykorean
fbshipit-source-id: fef51ea7c0fede6431c715bff116ddbb567c8752
2023-09-29 20:03:39 +00:00
|
|
|
std::string daily_offpeak_time_utc;
|
2016-09-23 23:34:04 +00:00
|
|
|
};
|
|
|
|
|
2021-05-11 23:14:33 +00:00
|
|
|
Status GetStringFromMutableDBOptions(const ConfigOptions& config_options,
|
|
|
|
const MutableDBOptions& mutable_opts,
|
|
|
|
std::string* opt_string);
|
|
|
|
|
|
|
|
Status GetMutableDBOptionsFromStrings(
|
|
|
|
const MutableDBOptions& base_options,
|
|
|
|
const std::unordered_map<std::string, std::string>& options_map,
|
|
|
|
MutableDBOptions* new_options);
|
2021-07-21 20:44:39 +00:00
|
|
|
|
|
|
|
bool MutableDBOptionsAreEqual(const MutableDBOptions& this_options,
|
|
|
|
const MutableDBOptions& that_options);
|
2021-05-11 23:14:33 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|