|
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
|
|
|
|
// 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).
|
|
|
|
|
|
|
|
|
|
#pragma once
|
|
|
|
|
|
|
|
|
|
#include <string>
|
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
|
|
#include "rocksdb/options.h"
|
|
|
|
|
|
|
|
|
|
namespace rocksdb {
|
|
|
|
|
|
|
|
|
|
struct ImmutableDBOptions {
|
|
|
|
|
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;
|
|
|
|
|
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;
|
|
|
|
|
std::string wal_dir;
|
|
|
|
|
uint32_t max_subcompactions;
|
|
|
|
|
int max_background_flushes;
|
|
|
|
|
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;
|
|
|
|
|
uint64_t wal_ttl_seconds;
|
|
|
|
|
uint64_t wal_size_limit_mb;
|
|
|
|
|
size_t manifest_preallocation_size;
|
|
|
|
|
bool allow_mmap_reads;
|
|
|
|
|
bool allow_mmap_writes;
|
|
|
|
|
bool use_direct_reads;
|
|
|
|
|
bool use_direct_io_for_flush_and_compaction;
|
|
|
|
|
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;
|
|
|
|
|
DBOptions::AccessHint access_hint_on_compaction_start;
|
|
|
|
|
bool new_table_reader_for_compaction_inputs;
|
|
|
|
|
size_t random_access_max_buffer_size;
|
|
|
|
|
bool use_adaptive_mutex;
|
|
|
|
|
std::vector<std::shared_ptr<EventListener>> listeners;
|
|
|
|
|
bool enable_thread_tracking;
|
|
|
|
|
bool enable_pipelined_write;
|
|
|
|
|
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;
|
|
|
|
|
WALRecoveryMode wal_recovery_mode;
|
|
|
|
|
bool allow_2pc;
|
|
|
|
|
std::shared_ptr<Cache> row_cache;
|
|
|
|
|
#ifndef ROCKSDB_LITE
|
|
|
|
|
WalFilter* wal_filter;
|
|
|
|
|
#endif // ROCKSDB_LITE
|
|
|
|
|
bool fail_if_options_file_error;
|
|
|
|
|
bool dump_malloc_stats;
|
|
|
|
|
bool avoid_flush_during_recovery;
|
|
|
|
|
bool 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
7 years ago
|
|
|
bool preserve_deletes;
|
|
|
|
|
bool two_write_queues;
|
|
|
|
|
bool manual_wal_flush;
|
|
|
|
|
bool atomic_flush;
|
|
|
|
|
bool avoid_unnecessary_blocking_io;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct MutableDBOptions {
|
|
|
|
|
MutableDBOptions();
|
|
|
|
|
explicit MutableDBOptions(const MutableDBOptions& options) = default;
|
|
|
|
|
explicit MutableDBOptions(const DBOptions& options);
|
|
|
|
|
|
|
|
|
|
void Dump(Logger* log) const;
|
|
|
|
|
|
|
|
|
|
int max_background_jobs;
|
|
|
|
|
int base_background_compactions;
|
|
|
|
|
int max_background_compactions;
|
|
|
|
|
bool avoid_flush_during_shutdown;
|
|
|
|
|
size_t writable_file_max_buffer_size;
|
|
|
|
|
uint64_t delayed_write_rate;
|
|
|
|
|
uint64_t max_total_wal_size;
|
|
|
|
|
uint64_t delete_obsolete_files_period_micros;
|
|
|
|
|
unsigned int stats_dump_period_sec;
|
|
|
|
|
unsigned int stats_persist_period_sec;
|
|
|
|
|
size_t stats_history_buffer_size;
|
|
|
|
|
int max_open_files;
|
|
|
|
|
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
6 years ago
|
|
|
bool strict_bytes_per_sync;
|
|
|
|
|
size_t compaction_readahead_size;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
} // namespace rocksdb
|
