2016-09-24 01:34:04 +02:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2017-07-16 01:03:42 +02: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-24 01:34:04 +02:00
|
|
|
|
2017-04-06 04:02:00 +02:00
|
|
|
#include "options/db_options.h"
|
2016-09-24 01:34:04 +02:00
|
|
|
|
2019-06-06 22:52:39 +02:00
|
|
|
#include <cinttypes>
|
2016-09-24 01:34:04 +02:00
|
|
|
|
2019-06-01 02:19:43 +02:00
|
|
|
#include "logging/logging.h"
|
2016-09-24 01:34:04 +02:00
|
|
|
#include "port/port.h"
|
|
|
|
|
#include "rocksdb/cache.h"
|
|
|
|
|
#include "rocksdb/env.h"
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 23:47:08 +01:00
|
|
|
#include "rocksdb/file_system.h"
|
2016-09-24 01:34:04 +02:00
|
|
|
#include "rocksdb/sst_file_manager.h"
|
|
|
|
|
#include "rocksdb/wal_filter.h"
|
|
|
|
|
|
|
|
|
|
namespace rocksdb {
|
|
|
|
|
|
|
|
|
|
ImmutableDBOptions::ImmutableDBOptions() : ImmutableDBOptions(Options()) {}
|
|
|
|
|
|
|
|
|
|
ImmutableDBOptions::ImmutableDBOptions(const DBOptions& options)
|
|
|
|
|
: create_if_missing(options.create_if_missing),
|
|
|
|
|
create_missing_column_families(options.create_missing_column_families),
|
|
|
|
|
error_if_exists(options.error_if_exists),
|
|
|
|
|
paranoid_checks(options.paranoid_checks),
|
|
|
|
|
env(options.env),
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 23:47:08 +01:00
|
|
|
fs(options.file_system),
|
2016-09-24 01:34:04 +02:00
|
|
|
rate_limiter(options.rate_limiter),
|
|
|
|
|
sst_file_manager(options.sst_file_manager),
|
|
|
|
|
info_log(options.info_log),
|
|
|
|
|
info_log_level(options.info_log_level),
|
|
|
|
|
max_file_opening_threads(options.max_file_opening_threads),
|
|
|
|
|
statistics(options.statistics),
|
|
|
|
|
use_fsync(options.use_fsync),
|
|
|
|
|
db_paths(options.db_paths),
|
|
|
|
|
db_log_dir(options.db_log_dir),
|
|
|
|
|
wal_dir(options.wal_dir),
|
|
|
|
|
max_subcompactions(options.max_subcompactions),
|
|
|
|
|
max_background_flushes(options.max_background_flushes),
|
|
|
|
|
max_log_file_size(options.max_log_file_size),
|
|
|
|
|
log_file_time_to_roll(options.log_file_time_to_roll),
|
|
|
|
|
keep_log_file_num(options.keep_log_file_num),
|
|
|
|
|
recycle_log_file_num(options.recycle_log_file_num),
|
|
|
|
|
max_manifest_file_size(options.max_manifest_file_size),
|
|
|
|
|
table_cache_numshardbits(options.table_cache_numshardbits),
|
|
|
|
|
wal_ttl_seconds(options.WAL_ttl_seconds),
|
|
|
|
|
wal_size_limit_mb(options.WAL_size_limit_MB),
|
2019-09-12 03:26:22 +02:00
|
|
|
max_write_batch_group_size_bytes(
|
|
|
|
|
options.max_write_batch_group_size_bytes),
|
2016-09-24 01:34:04 +02:00
|
|
|
manifest_preallocation_size(options.manifest_preallocation_size),
|
|
|
|
|
allow_mmap_reads(options.allow_mmap_reads),
|
|
|
|
|
allow_mmap_writes(options.allow_mmap_writes),
|
2016-10-28 19:36:05 +02:00
|
|
|
use_direct_reads(options.use_direct_reads),
|
2017-04-13 22:07:33 +02:00
|
|
|
use_direct_io_for_flush_and_compaction(
|
|
|
|
|
options.use_direct_io_for_flush_and_compaction),
|
2016-09-24 01:34:04 +02:00
|
|
|
allow_fallocate(options.allow_fallocate),
|
|
|
|
|
is_fd_close_on_exec(options.is_fd_close_on_exec),
|
|
|
|
|
advise_random_on_open(options.advise_random_on_open),
|
|
|
|
|
db_write_buffer_size(options.db_write_buffer_size),
|
|
|
|
|
write_buffer_manager(options.write_buffer_manager),
|
|
|
|
|
access_hint_on_compaction_start(options.access_hint_on_compaction_start),
|
|
|
|
|
new_table_reader_for_compaction_inputs(
|
|
|
|
|
options.new_table_reader_for_compaction_inputs),
|
|
|
|
|
random_access_max_buffer_size(options.random_access_max_buffer_size),
|
|
|
|
|
use_adaptive_mutex(options.use_adaptive_mutex),
|
|
|
|
|
listeners(options.listeners),
|
|
|
|
|
enable_thread_tracking(options.enable_thread_tracking),
|
2017-05-19 23:24:23 +02:00
|
|
|
enable_pipelined_write(options.enable_pipelined_write),
|
2019-05-14 02:43:47 +02:00
|
|
|
unordered_write(options.unordered_write),
|
2016-09-24 01:34:04 +02:00
|
|
|
allow_concurrent_memtable_write(options.allow_concurrent_memtable_write),
|
|
|
|
|
enable_write_thread_adaptive_yield(
|
|
|
|
|
options.enable_write_thread_adaptive_yield),
|
|
|
|
|
write_thread_max_yield_usec(options.write_thread_max_yield_usec),
|
|
|
|
|
write_thread_slow_yield_usec(options.write_thread_slow_yield_usec),
|
|
|
|
|
skip_stats_update_on_db_open(options.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 10:24:29 +01:00
|
|
|
skip_checking_sst_file_sizes_on_db_open(
|
|
|
|
|
options.skip_checking_sst_file_sizes_on_db_open),
|
2016-09-24 01:34:04 +02:00
|
|
|
wal_recovery_mode(options.wal_recovery_mode),
|
|
|
|
|
allow_2pc(options.allow_2pc),
|
|
|
|
|
row_cache(options.row_cache),
|
|
|
|
|
#ifndef ROCKSDB_LITE
|
|
|
|
|
wal_filter(options.wal_filter),
|
|
|
|
|
#endif // ROCKSDB_LITE
|
|
|
|
|
fail_if_options_file_error(options.fail_if_options_file_error),
|
|
|
|
|
dump_malloc_stats(options.dump_malloc_stats),
|
2017-05-17 20:32:26 +02:00
|
|
|
avoid_flush_during_recovery(options.avoid_flush_during_recovery),
|
2017-06-24 23:06:43 +02:00
|
|
|
allow_ingest_behind(options.allow_ingest_behind),
|
Added support for differential snapshots
Summary:
The motivation for this PR is to add to RocksDB support for differential (incremental) snapshots, as snapshot of the DB changes between two points in time (one can think of it as diff between to sequence numbers, or the diff D which can be thought of as an SST file or just set of KVs that can be applied to sequence number S1 to get the database to the state at sequence number S2).
This feature would be useful for various distributed storages layers built on top of RocksDB, as it should help reduce resources (time and network bandwidth) needed to recover and rebuilt DB instances as replicas in the context of distributed storages.
From the API standpoint that would like client app requesting iterator between (start seqnum) and current DB state, and reading the "diff".
This is a very draft PR for initial review in the discussion on the approach, i'm going to rework some parts and keep updating the PR.
For now, what's done here according to initial discussions:
Preserving deletes:
- We want to be able to optionally preserve recent deletes for some defined period of time, so that if a delete came in recently and might need to be included in the next incremental snapshot it would't get dropped by a compaction. This is done by adding new param to Options (preserve deletes flag) and new variable to DB Impl where we keep track of the sequence number after which we don't want to drop tombstones, even if they are otherwise eligible for deletion.
- I also added a new API call for clients to be able to advance this cutoff seqnum after which we drop deletes; i assume it's more flexible to let clients control this, since otherwise we'd need to keep some kind of timestamp < -- > seqnum mapping inside the DB, which sounds messy and painful to support. Clients could make use of it by periodically calling GetLatestSequenceNumber(), noting the timestamp, doing some calculation and figuring out by how much we need to advance the cutoff seqnum.
- Compaction codepath in compaction_iterator.cc has been modified to avoid dropping tombstones with seqnum > cutoff seqnum.
Iterator changes:
- couple params added to ReadOptions, to optionally allow client to request internal keys instead of user keys (so that client can get the latest value of a key, be it delete marker or a put), as well as min timestamp and min seqnum.
TableCache changes:
- I modified table_cache code to be able to quickly exclude SST files from iterators heep if creation_time on the file is less then iter_start_ts as passed in ReadOptions. That would help a lot in some DB settings (like reading very recent data only or using FIFO compactions), but not so much for universal compaction with more or less long iterator time span.
What's left:
- Still looking at how to best plug that inside DBIter codepath. So far it seems that FindNextUserKeyInternal only parses values as UserKeys, and iter->key() call generally returns user key. Can we add new API to DBIter as internal_key(), and modify this internal method to optionally set saved_key_ to point to the full internal key? I don't need to store actual seqnum there, but I do need to store type.
Closes https://github.com/facebook/rocksdb/pull/2999
Differential Revision: D6175602
Pulled By: mikhail-antonov
fbshipit-source-id: c779a6696ee2d574d86c69cec866a3ae095aa900
2017-11-02 02:43:29 +01:00
|
|
|
preserve_deletes(options.preserve_deletes),
|
2017-11-11 02:18:01 +01:00
|
|
|
two_write_queues(options.two_write_queues),
|
2018-11-12 21:22:10 +01:00
|
|
|
manual_wal_flush(options.manual_wal_flush),
|
2019-04-02 02:07:38 +02:00
|
|
|
atomic_flush(options.atomic_flush),
|
2019-06-18 00:17:43 +02:00
|
|
|
avoid_unnecessary_blocking_io(options.avoid_unnecessary_blocking_io),
|
2019-07-19 20:54:38 +02:00
|
|
|
persist_stats_to_disk(options.persist_stats_to_disk),
|
2019-09-03 17:50:47 +02:00
|
|
|
write_dbid_to_manifest(options.write_dbid_to_manifest),
|
2019-07-19 20:54:38 +02:00
|
|
|
log_readahead_size(options.log_readahead_size) {
|
2016-09-24 01:34:04 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void ImmutableDBOptions::Dump(Logger* log) const {
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.error_if_exists: %d",
|
|
|
|
|
error_if_exists);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.create_if_missing: %d",
|
|
|
|
|
create_if_missing);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.paranoid_checks: %d",
|
|
|
|
|
paranoid_checks);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.env: %p",
|
|
|
|
|
env);
|
Introduce a new storage specific Env API (#5761)
Summary:
The current Env API encompasses both storage/file operations, as well as OS related operations. Most of the APIs return a Status, which does not have enough metadata about an error, such as whether its retry-able or not, scope (i.e fault domain) of the error etc., that may be required in order to properly handle a storage error. The file APIs also do not provide enough control over the IO SLA, such as timeout, prioritization, hinting about placement and redundancy etc.
This PR separates out the file/storage APIs from Env into a new FileSystem class. The APIs are updated to return an IOStatus with metadata about the error, as well as to take an IOOptions structure as input in order to allow more control over the IO.
The user can set both ```options.env``` and ```options.file_system``` to specify that RocksDB should use the former for OS related operations and the latter for storage operations. Internally, a ```CompositeEnvWrapper``` has been introduced that inherits from ```Env``` and redirects individual methods to either an ```Env``` implementation or the ```FileSystem``` as appropriate. When options are sanitized during ```DB::Open```, ```options.env``` is replaced with a newly allocated ```CompositeEnvWrapper``` instance if both env and file_system have been specified. This way, the rest of the RocksDB code can continue to function as before.
This PR also ports PosixEnv to the new API by splitting it into two - PosixEnv and PosixFileSystem. PosixEnv is defined as a sub-class of CompositeEnvWrapper, and threading/time functions are overridden with Posix specific implementations in order to avoid an extra level of indirection.
The ```CompositeEnvWrapper``` translates ```IOStatus``` return code to ```Status```, and sets the severity to ```kSoftError``` if the io_status is retryable. The error handling code in RocksDB can then recover the DB automatically.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5761
Differential Revision: D18868376
Pulled By: anand1976
fbshipit-source-id: 39efe18a162ea746fabac6360ff529baba48486f
2019-12-13 23:47:08 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.fs: %s",
|
|
|
|
|
fs->Name());
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.info_log: %p",
|
|
|
|
|
info_log.get());
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.max_file_opening_threads: %d",
|
|
|
|
|
max_file_opening_threads);
|
2017-09-01 01:21:15 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.statistics: %p",
|
|
|
|
|
statistics.get());
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.use_fsync: %d",
|
|
|
|
|
use_fsync);
|
|
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.max_log_file_size: %" ROCKSDB_PRIszt,
|
|
|
|
|
max_log_file_size);
|
|
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.max_manifest_file_size: %" PRIu64,
|
|
|
|
|
max_manifest_file_size);
|
|
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.log_file_time_to_roll: %" ROCKSDB_PRIszt,
|
|
|
|
|
log_file_time_to_roll);
|
|
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.keep_log_file_num: %" ROCKSDB_PRIszt,
|
|
|
|
|
keep_log_file_num);
|
|
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.recycle_log_file_num: %" ROCKSDB_PRIszt,
|
|
|
|
|
recycle_log_file_num);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.allow_fallocate: %d",
|
|
|
|
|
allow_fallocate);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.allow_mmap_reads: %d",
|
|
|
|
|
allow_mmap_reads);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.allow_mmap_writes: %d",
|
|
|
|
|
allow_mmap_writes);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.use_direct_reads: %d",
|
|
|
|
|
use_direct_reads);
|
2017-04-13 22:07:33 +02:00
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" "
|
|
|
|
|
"Options.use_direct_io_for_flush_and_compaction: %d",
|
|
|
|
|
use_direct_io_for_flush_and_compaction);
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.create_missing_column_families: %d",
|
|
|
|
|
create_missing_column_families);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.db_log_dir: %s",
|
|
|
|
|
db_log_dir.c_str());
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.wal_dir: %s",
|
|
|
|
|
wal_dir.c_str());
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.table_cache_numshardbits: %d",
|
|
|
|
|
table_cache_numshardbits);
|
|
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.max_subcompactions: %" PRIu32,
|
|
|
|
|
max_subcompactions);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.max_background_flushes: %d",
|
|
|
|
|
max_background_flushes);
|
|
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.WAL_ttl_seconds: %" PRIu64,
|
|
|
|
|
wal_ttl_seconds);
|
|
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.WAL_size_limit_MB: %" PRIu64,
|
|
|
|
|
wal_size_limit_mb);
|
2019-09-12 03:26:22 +02:00
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" "
|
|
|
|
|
"Options.max_write_batch_group_size_bytes: %" PRIu64,
|
|
|
|
|
max_write_batch_group_size_bytes);
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.manifest_preallocation_size: %" ROCKSDB_PRIszt,
|
|
|
|
|
manifest_preallocation_size);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.is_fd_close_on_exec: %d",
|
|
|
|
|
is_fd_close_on_exec);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.advise_random_on_open: %d",
|
|
|
|
|
advise_random_on_open);
|
|
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.db_write_buffer_size: %" ROCKSDB_PRIszt,
|
|
|
|
|
db_write_buffer_size);
|
2017-07-18 21:40:17 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.write_buffer_manager: %p",
|
|
|
|
|
write_buffer_manager.get());
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.access_hint_on_compaction_start: %d",
|
|
|
|
|
static_cast<int>(access_hint_on_compaction_start));
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.new_table_reader_for_compaction_inputs: %d",
|
|
|
|
|
new_table_reader_for_compaction_inputs);
|
|
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.random_access_max_buffer_size: %" ROCKSDB_PRIszt,
|
|
|
|
|
random_access_max_buffer_size);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.use_adaptive_mutex: %d",
|
|
|
|
|
use_adaptive_mutex);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.rate_limiter: %p",
|
|
|
|
|
rate_limiter.get());
|
2016-09-24 01:34:04 +02:00
|
|
|
Header(
|
|
|
|
|
log, " Options.sst_file_manager.rate_bytes_per_sec: %" PRIi64,
|
|
|
|
|
sst_file_manager ? sst_file_manager->GetDeleteRateBytesPerSecond() : 0);
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.wal_recovery_mode: %d",
|
2019-04-04 21:05:42 +02:00
|
|
|
static_cast<int>(wal_recovery_mode));
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.enable_thread_tracking: %d",
|
|
|
|
|
enable_thread_tracking);
|
2017-05-19 23:24:23 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.enable_pipelined_write: %d",
|
|
|
|
|
enable_pipelined_write);
|
2019-05-14 02:43:47 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.unordered_write: %d",
|
|
|
|
|
unordered_write);
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.allow_concurrent_memtable_write: %d",
|
|
|
|
|
allow_concurrent_memtable_write);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.enable_write_thread_adaptive_yield: %d",
|
|
|
|
|
enable_write_thread_adaptive_yield);
|
|
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.write_thread_max_yield_usec: %" PRIu64,
|
|
|
|
|
write_thread_max_yield_usec);
|
|
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.write_thread_slow_yield_usec: %" PRIu64,
|
|
|
|
|
write_thread_slow_yield_usec);
|
2016-09-24 01:34:04 +02:00
|
|
|
if (row_cache) {
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(
|
2019-04-04 21:05:42 +02:00
|
|
|
log,
|
|
|
|
|
" Options.row_cache: %" ROCKSDB_PRIszt,
|
2017-03-16 03:22:52 +01:00
|
|
|
row_cache->GetCapacity());
|
2016-09-24 01:34:04 +02:00
|
|
|
} else {
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.row_cache: None");
|
2016-09-24 01:34:04 +02:00
|
|
|
}
|
|
|
|
|
#ifndef ROCKSDB_LITE
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.wal_filter: %s",
|
|
|
|
|
wal_filter ? wal_filter->Name() : "None");
|
2016-09-24 01:34:04 +02:00
|
|
|
#endif // ROCKDB_LITE
|
2017-05-17 20:32:26 +02:00
|
|
|
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.avoid_flush_during_recovery: %d",
|
|
|
|
|
avoid_flush_during_recovery);
|
2017-05-17 20:32:26 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.allow_ingest_behind: %d",
|
|
|
|
|
allow_ingest_behind);
|
Added support for differential snapshots
Summary:
The motivation for this PR is to add to RocksDB support for differential (incremental) snapshots, as snapshot of the DB changes between two points in time (one can think of it as diff between to sequence numbers, or the diff D which can be thought of as an SST file or just set of KVs that can be applied to sequence number S1 to get the database to the state at sequence number S2).
This feature would be useful for various distributed storages layers built on top of RocksDB, as it should help reduce resources (time and network bandwidth) needed to recover and rebuilt DB instances as replicas in the context of distributed storages.
From the API standpoint that would like client app requesting iterator between (start seqnum) and current DB state, and reading the "diff".
This is a very draft PR for initial review in the discussion on the approach, i'm going to rework some parts and keep updating the PR.
For now, what's done here according to initial discussions:
Preserving deletes:
- We want to be able to optionally preserve recent deletes for some defined period of time, so that if a delete came in recently and might need to be included in the next incremental snapshot it would't get dropped by a compaction. This is done by adding new param to Options (preserve deletes flag) and new variable to DB Impl where we keep track of the sequence number after which we don't want to drop tombstones, even if they are otherwise eligible for deletion.
- I also added a new API call for clients to be able to advance this cutoff seqnum after which we drop deletes; i assume it's more flexible to let clients control this, since otherwise we'd need to keep some kind of timestamp < -- > seqnum mapping inside the DB, which sounds messy and painful to support. Clients could make use of it by periodically calling GetLatestSequenceNumber(), noting the timestamp, doing some calculation and figuring out by how much we need to advance the cutoff seqnum.
- Compaction codepath in compaction_iterator.cc has been modified to avoid dropping tombstones with seqnum > cutoff seqnum.
Iterator changes:
- couple params added to ReadOptions, to optionally allow client to request internal keys instead of user keys (so that client can get the latest value of a key, be it delete marker or a put), as well as min timestamp and min seqnum.
TableCache changes:
- I modified table_cache code to be able to quickly exclude SST files from iterators heep if creation_time on the file is less then iter_start_ts as passed in ReadOptions. That would help a lot in some DB settings (like reading very recent data only or using FIFO compactions), but not so much for universal compaction with more or less long iterator time span.
What's left:
- Still looking at how to best plug that inside DBIter codepath. So far it seems that FindNextUserKeyInternal only parses values as UserKeys, and iter->key() call generally returns user key. Can we add new API to DBIter as internal_key(), and modify this internal method to optionally set saved_key_ to point to the full internal key? I don't need to store actual seqnum there, but I do need to store type.
Closes https://github.com/facebook/rocksdb/pull/2999
Differential Revision: D6175602
Pulled By: mikhail-antonov
fbshipit-source-id: c779a6696ee2d574d86c69cec866a3ae095aa900
2017-11-02 02:43:29 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.preserve_deletes: %d",
|
|
|
|
|
preserve_deletes);
|
2017-11-11 02:18:01 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.two_write_queues: %d",
|
|
|
|
|
two_write_queues);
|
2017-06-24 23:06:43 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.manual_wal_flush: %d",
|
|
|
|
|
manual_wal_flush);
|
2019-04-02 02:07:38 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.atomic_flush: %d", atomic_flush);
|
|
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.avoid_unnecessary_blocking_io: %d",
|
|
|
|
|
avoid_unnecessary_blocking_io);
|
2019-06-18 00:17:43 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.persist_stats_to_disk: %u",
|
|
|
|
|
persist_stats_to_disk);
|
2019-09-03 17:50:47 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.write_dbid_to_manifest: %d",
|
|
|
|
|
write_dbid_to_manifest);
|
2019-07-19 20:54:38 +02:00
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.log_readahead_size: %" ROCKSDB_PRIszt,
|
|
|
|
|
log_readahead_size);
|
2016-09-24 01:34:04 +02:00
|
|
|
}
|
|
|
|
|
|
2016-10-14 21:25:39 +02:00
|
|
|
MutableDBOptions::MutableDBOptions()
|
2017-05-24 20:25:38 +02:00
|
|
|
: max_background_jobs(2),
|
|
|
|
|
base_background_compactions(-1),
|
|
|
|
|
max_background_compactions(-1),
|
2016-11-13 00:43:33 +01:00
|
|
|
avoid_flush_during_shutdown(false),
|
2017-10-31 21:49:25 +01:00
|
|
|
writable_file_max_buffer_size(1024 * 1024),
|
2016-11-15 07:45:16 +01:00
|
|
|
delayed_write_rate(2 * 1024U * 1024U),
|
2016-12-05 23:09:35 +01:00
|
|
|
max_total_wal_size(0),
|
2017-03-21 06:50:56 +01:00
|
|
|
delete_obsolete_files_period_micros(6ULL * 60 * 60 * 1000000),
|
2017-05-04 05:46:17 +02:00
|
|
|
stats_dump_period_sec(600),
|
2019-02-21 00:46:59 +01:00
|
|
|
stats_persist_period_sec(600),
|
|
|
|
|
stats_history_buffer_size(1024 * 1024),
|
2017-10-27 05:54:48 +02:00
|
|
|
max_open_files(-1),
|
|
|
|
|
bytes_per_sync(0),
|
2017-11-17 02:46:43 +01:00
|
|
|
wal_bytes_per_sync(0),
|
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 20:48:45 +02:00
|
|
|
strict_bytes_per_sync(false),
|
2017-11-17 02:46:43 +01:00
|
|
|
compaction_readahead_size(0) {}
|
2016-10-14 21:25:39 +02:00
|
|
|
|
|
|
|
|
MutableDBOptions::MutableDBOptions(const DBOptions& options)
|
2017-05-24 20:25:38 +02:00
|
|
|
: max_background_jobs(options.max_background_jobs),
|
|
|
|
|
base_background_compactions(options.base_background_compactions),
|
2016-11-02 23:22:13 +01:00
|
|
|
max_background_compactions(options.max_background_compactions),
|
2016-11-13 00:43:33 +01:00
|
|
|
avoid_flush_during_shutdown(options.avoid_flush_during_shutdown),
|
2017-10-31 21:49:25 +01:00
|
|
|
writable_file_max_buffer_size(options.writable_file_max_buffer_size),
|
2016-11-15 07:45:16 +01:00
|
|
|
delayed_write_rate(options.delayed_write_rate),
|
2016-12-05 23:09:35 +01:00
|
|
|
max_total_wal_size(options.max_total_wal_size),
|
|
|
|
|
delete_obsolete_files_period_micros(
|
2017-03-21 06:50:56 +01:00
|
|
|
options.delete_obsolete_files_period_micros),
|
2017-05-04 05:46:17 +02:00
|
|
|
stats_dump_period_sec(options.stats_dump_period_sec),
|
2019-02-21 00:46:59 +01:00
|
|
|
stats_persist_period_sec(options.stats_persist_period_sec),
|
|
|
|
|
stats_history_buffer_size(options.stats_history_buffer_size),
|
2017-09-28 02:37:08 +02:00
|
|
|
max_open_files(options.max_open_files),
|
|
|
|
|
bytes_per_sync(options.bytes_per_sync),
|
2017-11-17 02:46:43 +01:00
|
|
|
wal_bytes_per_sync(options.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 20:48:45 +02:00
|
|
|
strict_bytes_per_sync(options.strict_bytes_per_sync),
|
2017-11-17 02:46:43 +01:00
|
|
|
compaction_readahead_size(options.compaction_readahead_size) {}
|
2016-09-24 01:34:04 +02:00
|
|
|
|
2016-10-14 21:25:39 +02:00
|
|
|
void MutableDBOptions::Dump(Logger* log) const {
|
2017-05-24 20:25:38 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.max_background_jobs: %d",
|
|
|
|
|
max_background_jobs);
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.max_background_compactions: %d",
|
|
|
|
|
max_background_compactions);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.avoid_flush_during_shutdown: %d",
|
|
|
|
|
avoid_flush_during_shutdown);
|
2017-10-31 21:49:25 +01:00
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.writable_file_max_buffer_size: %" ROCKSDB_PRIszt,
|
|
|
|
|
writable_file_max_buffer_size);
|
2017-03-16 03:22:52 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.delayed_write_rate : %" PRIu64,
|
|
|
|
|
delayed_write_rate);
|
|
|
|
|
ROCKS_LOG_HEADER(log, " Options.max_total_wal_size: %" PRIu64,
|
|
|
|
|
max_total_wal_size);
|
|
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log, " Options.delete_obsolete_files_period_micros: %" PRIu64,
|
|
|
|
|
delete_obsolete_files_period_micros);
|
2017-03-21 06:50:56 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.stats_dump_period_sec: %u",
|
|
|
|
|
stats_dump_period_sec);
|
2019-02-21 00:46:59 +01:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.stats_persist_period_sec: %d",
|
|
|
|
|
stats_persist_period_sec);
|
2019-04-04 21:05:42 +02:00
|
|
|
ROCKS_LOG_HEADER(
|
|
|
|
|
log,
|
|
|
|
|
" Options.stats_history_buffer_size: %" ROCKSDB_PRIszt,
|
|
|
|
|
stats_history_buffer_size);
|
2017-05-04 05:46:17 +02:00
|
|
|
ROCKS_LOG_HEADER(log, " Options.max_open_files: %d",
|
|
|
|
|
max_open_files);
|
2017-09-28 02:37:08 +02:00
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.bytes_per_sync: %" PRIu64,
|
|
|
|
|
bytes_per_sync);
|
|
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.wal_bytes_per_sync: %" PRIu64,
|
|
|
|
|
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 20:48:45 +02:00
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.strict_bytes_per_sync: %d",
|
|
|
|
|
strict_bytes_per_sync);
|
2017-11-17 02:46:43 +01:00
|
|
|
ROCKS_LOG_HEADER(log,
|
|
|
|
|
" Options.compaction_readahead_size: %" ROCKSDB_PRIszt,
|
|
|
|
|
compaction_readahead_size);
|
2016-10-14 21:25:39 +02:00
|
|
|
}
|
2016-09-24 01:34:04 +02:00
|
|
|
|
|
|
|
|
} // namespace rocksdb
|
