2017-04-06 02:14:05 +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).
|
2017-04-06 02:14:05 +02:00
|
|
|
//
|
|
|
|
// Copyright (c) 2011 The LevelDB Authors. All rights reserved.
|
|
|
|
// Use of this source code is governed by a BSD-style license that can be
|
|
|
|
// found in the LICENSE file. See the AUTHORS file for names of contributors.
|
2019-06-06 22:52:39 +02:00
|
|
|
#include <cinttypes>
|
2020-07-03 04:24:25 +02:00
|
|
|
|
|
|
|
#include "db/db_impl/db_impl.h"
|
2018-06-28 21:23:57 +02:00
|
|
|
#include "db/error_handler.h"
|
2017-06-23 04:30:39 +02:00
|
|
|
#include "db/event_helpers.h"
|
2021-09-29 13:01:57 +02:00
|
|
|
#include "logging/logging.h"
|
2017-04-06 04:02:00 +02:00
|
|
|
#include "monitoring/perf_context_imp.h"
|
2017-04-07 05:06:34 +02:00
|
|
|
#include "options/options_helper.h"
|
2019-05-30 20:21:38 +02:00
|
|
|
#include "test_util/sync_point.h"
|
2020-07-03 04:24:25 +02:00
|
|
|
#include "util/cast_util.h"
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2020-02-20 21:07:53 +01:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2017-04-06 02:14:05 +02:00
|
|
|
// Convenience methods
|
|
|
|
Status DBImpl::Put(const WriteOptions& o, ColumnFamilyHandle* column_family,
|
|
|
|
const Slice& key, const Slice& val) {
|
|
|
|
return DB::Put(o, column_family, key, val);
|
|
|
|
}
|
|
|
|
|
|
|
|
Status DBImpl::Merge(const WriteOptions& o, ColumnFamilyHandle* column_family,
|
|
|
|
const Slice& key, const Slice& val) {
|
2020-07-03 04:24:25 +02:00
|
|
|
auto cfh = static_cast_with_check<ColumnFamilyHandleImpl>(column_family);
|
2017-04-06 02:14:05 +02:00
|
|
|
if (!cfh->cfd()->ioptions()->merge_operator) {
|
|
|
|
return Status::NotSupported("Provide a merge_operator when opening DB");
|
|
|
|
} else {
|
|
|
|
return DB::Merge(o, column_family, key, val);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
Status DBImpl::Delete(const WriteOptions& write_options,
|
|
|
|
ColumnFamilyHandle* column_family, const Slice& key) {
|
|
|
|
return DB::Delete(write_options, column_family, key);
|
|
|
|
}
|
|
|
|
|
|
|
|
Status DBImpl::SingleDelete(const WriteOptions& write_options,
|
|
|
|
ColumnFamilyHandle* column_family,
|
|
|
|
const Slice& key) {
|
|
|
|
return DB::SingleDelete(write_options, column_family, key);
|
|
|
|
}
|
|
|
|
|
2018-03-28 21:01:09 +02:00
|
|
|
void DBImpl::SetRecoverableStatePreReleaseCallback(
|
|
|
|
PreReleaseCallback* callback) {
|
|
|
|
recoverable_state_pre_release_callback_.reset(callback);
|
|
|
|
}
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
Status DBImpl::Write(const WriteOptions& write_options, WriteBatch* my_batch) {
|
|
|
|
return WriteImpl(write_options, my_batch, nullptr, nullptr);
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef ROCKSDB_LITE
|
|
|
|
Status DBImpl::WriteWithCallback(const WriteOptions& write_options,
|
|
|
|
WriteBatch* my_batch,
|
|
|
|
WriteCallback* callback) {
|
|
|
|
return WriteImpl(write_options, my_batch, callback, nullptr);
|
|
|
|
}
|
|
|
|
#endif // ROCKSDB_LITE
|
|
|
|
|
2017-12-01 08:39:56 +01:00
|
|
|
// The main write queue. This is the only write queue that updates LastSequence.
|
|
|
|
// When using one write queue, the same sequence also indicates the last
|
|
|
|
// published sequence.
|
2017-04-06 02:14:05 +02:00
|
|
|
Status DBImpl::WriteImpl(const WriteOptions& write_options,
|
|
|
|
WriteBatch* my_batch, WriteCallback* callback,
|
|
|
|
uint64_t* log_used, uint64_t log_ref,
|
2017-12-01 08:39:56 +01:00
|
|
|
bool disable_memtable, uint64_t* seq_used,
|
2018-02-06 03:32:54 +01:00
|
|
|
size_t batch_cnt,
|
2017-12-01 08:39:56 +01:00
|
|
|
PreReleaseCallback* pre_release_callback) {
|
2018-02-06 03:32:54 +01:00
|
|
|
assert(!seq_per_batch_ || batch_cnt != 0);
|
2017-04-06 02:14:05 +02:00
|
|
|
if (my_batch == nullptr) {
|
|
|
|
return Status::Corruption("Batch is nullptr!");
|
|
|
|
}
|
2018-08-01 09:14:43 +02:00
|
|
|
if (tracer_) {
|
|
|
|
InstrumentedMutexLock lock(&trace_mutex_);
|
|
|
|
if (tracer_) {
|
2020-10-02 00:57:28 +02:00
|
|
|
// TODO: maybe handle the tracing status?
|
|
|
|
tracer_->Write(my_batch).PermitUncheckedError();
|
2018-08-01 09:14:43 +02:00
|
|
|
}
|
|
|
|
}
|
2017-10-29 05:56:50 +01:00
|
|
|
if (write_options.sync && write_options.disableWAL) {
|
|
|
|
return Status::InvalidArgument("Sync writes has to enable WAL.");
|
|
|
|
}
|
2017-11-11 02:18:01 +01:00
|
|
|
if (two_write_queues_ && immutable_db_options_.enable_pipelined_write) {
|
2017-06-24 23:06:43 +02:00
|
|
|
return Status::NotSupported(
|
|
|
|
"pipelined_writes is not compatible with concurrent prepares");
|
|
|
|
}
|
2017-09-18 23:36:53 +02:00
|
|
|
if (seq_per_batch_ && immutable_db_options_.enable_pipelined_write) {
|
2018-02-06 03:32:54 +01:00
|
|
|
// TODO(yiwu): update pipeline write with seq_per_batch and batch_cnt
|
2017-09-18 23:36:53 +02:00
|
|
|
return Status::NotSupported(
|
|
|
|
"pipelined_writes is not compatible with seq_per_batch");
|
|
|
|
}
|
2019-05-14 02:43:47 +02:00
|
|
|
if (immutable_db_options_.unordered_write &&
|
|
|
|
immutable_db_options_.enable_pipelined_write) {
|
|
|
|
return Status::NotSupported(
|
|
|
|
"pipelined_writes is not compatible with unordered_write");
|
|
|
|
}
|
2017-11-02 01:23:52 +01:00
|
|
|
// Otherwise IsLatestPersistentState optimization does not make sense
|
|
|
|
assert(!WriteBatchInternal::IsLatestPersistentState(my_batch) ||
|
|
|
|
disable_memtable);
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2017-06-05 23:42:34 +02:00
|
|
|
if (write_options.low_pri) {
|
2020-09-29 18:47:33 +02:00
|
|
|
Status s = ThrottleLowPriWritesIfNeeded(write_options, my_batch);
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
2017-06-05 23:42:34 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-11 02:18:01 +01:00
|
|
|
if (two_write_queues_ && disable_memtable) {
|
2019-05-14 02:43:47 +02:00
|
|
|
AssignOrder assign_order =
|
|
|
|
seq_per_batch_ ? kDoAssignOrder : kDontAssignOrder;
|
|
|
|
// Otherwise it is WAL-only Prepare batches in WriteCommitted policy and
|
|
|
|
// they don't consume sequence.
|
|
|
|
return WriteImplWALOnly(&nonmem_write_thread_, write_options, my_batch,
|
|
|
|
callback, log_used, log_ref, seq_used, batch_cnt,
|
|
|
|
pre_release_callback, assign_order,
|
|
|
|
kDontPublishLastSeq, disable_memtable);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (immutable_db_options_.unordered_write) {
|
|
|
|
const size_t sub_batch_cnt = batch_cnt != 0
|
|
|
|
? batch_cnt
|
|
|
|
// every key is a sub-batch consuming a seq
|
|
|
|
: WriteBatchInternal::Count(my_batch);
|
2020-10-08 05:09:28 +02:00
|
|
|
uint64_t seq = 0;
|
2019-05-14 02:43:47 +02:00
|
|
|
// Use a write thread to i) optimize for WAL write, ii) publish last
|
|
|
|
// sequence in in increasing order, iii) call pre_release_callback serially
|
2020-09-29 18:47:33 +02:00
|
|
|
Status status = WriteImplWALOnly(
|
|
|
|
&write_thread_, write_options, my_batch, callback, log_used, log_ref,
|
|
|
|
&seq, sub_batch_cnt, pre_release_callback, kDoAssignOrder,
|
|
|
|
kDoPublishLastSeq, disable_memtable);
|
2019-12-12 23:05:48 +01:00
|
|
|
TEST_SYNC_POINT("DBImpl::WriteImpl:UnorderedWriteAfterWriteWAL");
|
2019-05-14 02:43:47 +02:00
|
|
|
if (!status.ok()) {
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
if (seq_used) {
|
|
|
|
*seq_used = seq;
|
|
|
|
}
|
|
|
|
if (!disable_memtable) {
|
2019-12-12 23:05:48 +01:00
|
|
|
TEST_SYNC_POINT("DBImpl::WriteImpl:BeforeUnorderedWriteMemtable");
|
2019-05-14 02:43:47 +02:00
|
|
|
status = UnorderedWriteMemtable(write_options, my_batch, callback,
|
|
|
|
log_ref, seq, sub_batch_cnt);
|
|
|
|
}
|
|
|
|
return status;
|
2017-06-24 23:06:43 +02:00
|
|
|
}
|
|
|
|
|
2017-05-19 23:24:23 +02:00
|
|
|
if (immutable_db_options_.enable_pipelined_write) {
|
|
|
|
return PipelinedWriteImpl(write_options, my_batch, callback, log_used,
|
2017-08-17 01:49:11 +02:00
|
|
|
log_ref, disable_memtable, seq_used);
|
2017-05-19 23:24:23 +02:00
|
|
|
}
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
PERF_TIMER_GUARD(write_pre_and_post_process_time);
|
|
|
|
WriteThread::Writer w(write_options, my_batch, callback, log_ref,
|
2018-02-06 03:32:54 +01:00
|
|
|
disable_memtable, batch_cnt, pre_release_callback);
|
2021-10-20 23:03:44 +02:00
|
|
|
StopWatch write_sw(immutable_db_options_.clock, stats_, DB_WRITE);
|
2017-04-06 02:14:05 +02:00
|
|
|
|
|
|
|
write_thread_.JoinBatchGroup(&w);
|
2017-05-19 23:24:23 +02:00
|
|
|
if (w.state == WriteThread::STATE_PARALLEL_MEMTABLE_WRITER) {
|
2017-04-06 02:14:05 +02:00
|
|
|
// we are a non-leader in a parallel group
|
|
|
|
|
|
|
|
if (w.ShouldWriteToMemtable()) {
|
2018-04-24 02:53:27 +02:00
|
|
|
PERF_TIMER_STOP(write_pre_and_post_process_time);
|
|
|
|
PERF_TIMER_GUARD(write_memtable_time);
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
ColumnFamilyMemTablesImpl column_family_memtables(
|
|
|
|
versions_->GetColumnFamilySet());
|
|
|
|
w.status = WriteBatchInternal::InsertInto(
|
2017-05-31 19:45:47 +02:00
|
|
|
&w, w.sequence, &column_family_memtables, &flush_scheduler_,
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
&trim_history_scheduler_,
|
2017-04-06 02:14:05 +02:00
|
|
|
write_options.ignore_missing_column_families, 0 /*log_number*/, this,
|
2019-07-23 17:04:58 +02:00
|
|
|
true /*concurrent_memtable_writes*/, seq_per_batch_, w.batch_cnt,
|
2019-09-13 01:53:31 +02:00
|
|
|
batch_per_txn_, write_options.memtable_insert_hint_per_batch);
|
2018-04-24 02:53:27 +02:00
|
|
|
|
|
|
|
PERF_TIMER_START(write_pre_and_post_process_time);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
2017-05-19 23:24:23 +02:00
|
|
|
if (write_thread_.CompleteParallelMemTableWriter(&w)) {
|
2017-04-13 23:46:25 +02:00
|
|
|
// we're responsible for exit batch group
|
2017-12-01 08:39:56 +01:00
|
|
|
// TODO(myabandeh): propagate status to write_group
|
2017-05-19 23:24:23 +02:00
|
|
|
auto last_sequence = w.write_group->last_sequence;
|
2017-04-06 02:14:05 +02:00
|
|
|
versions_->SetLastSequence(last_sequence);
|
2017-05-19 23:24:23 +02:00
|
|
|
MemTableInsertStatusCheck(w.status);
|
2017-04-13 23:46:25 +02:00
|
|
|
write_thread_.ExitAsBatchGroupFollower(&w);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
assert(w.state == WriteThread::STATE_COMPLETED);
|
|
|
|
// STATE_COMPLETED conditional below handles exit
|
|
|
|
}
|
|
|
|
if (w.state == WriteThread::STATE_COMPLETED) {
|
|
|
|
if (log_used != nullptr) {
|
|
|
|
*log_used = w.log_used;
|
|
|
|
}
|
2017-08-17 01:49:11 +02:00
|
|
|
if (seq_used != nullptr) {
|
|
|
|
*seq_used = w.sequence;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
// write is complete and leader has updated sequence
|
|
|
|
return w.FinalStatus();
|
|
|
|
}
|
|
|
|
// else we are the leader of the write batch group
|
|
|
|
assert(w.state == WriteThread::STATE_GROUP_LEADER);
|
2020-12-23 08:44:44 +01:00
|
|
|
Status status;
|
2017-04-06 02:14:05 +02:00
|
|
|
// Once reaches this point, the current writer "w" will try to do its write
|
|
|
|
// job. It may also pick up some of the remaining writers in the "writers_"
|
|
|
|
// when it finds suitable, and finish them in the same write batch.
|
|
|
|
// This is how a write job could be done by the other writer.
|
|
|
|
WriteContext write_context;
|
2017-05-19 23:24:23 +02:00
|
|
|
WriteThread::WriteGroup write_group;
|
2017-04-13 23:46:25 +02:00
|
|
|
bool in_parallel_group = false;
|
2017-06-29 00:36:11 +02:00
|
|
|
uint64_t last_sequence = kMaxSequenceNumber;
|
2017-04-06 02:14:05 +02:00
|
|
|
|
|
|
|
mutex_.Lock();
|
|
|
|
|
2017-10-29 05:56:50 +01:00
|
|
|
bool need_log_sync = write_options.sync;
|
2017-04-06 02:14:05 +02:00
|
|
|
bool need_log_dir_sync = need_log_sync && !log_dir_synced_;
|
2021-07-30 21:06:47 +02:00
|
|
|
assert(!two_write_queues_ || !disable_memtable);
|
|
|
|
{
|
2017-06-24 23:06:43 +02:00
|
|
|
// With concurrent writes we do preprocess only in the write thread that
|
|
|
|
// also does write to memtable to avoid sync issue on shared data structure
|
|
|
|
// with the other thread
|
2018-04-24 02:53:27 +02:00
|
|
|
|
|
|
|
// PreprocessWrite does its own perf timing.
|
|
|
|
PERF_TIMER_STOP(write_pre_and_post_process_time);
|
|
|
|
|
2017-06-24 23:06:43 +02:00
|
|
|
status = PreprocessWrite(write_options, &need_log_sync, &write_context);
|
2019-05-15 22:48:59 +02:00
|
|
|
if (!two_write_queues_) {
|
|
|
|
// Assign it after ::PreprocessWrite since the sequence might advance
|
|
|
|
// inside it by WriteRecoverableState
|
|
|
|
last_sequence = versions_->LastSequence();
|
|
|
|
}
|
2018-04-24 02:53:27 +02:00
|
|
|
|
|
|
|
PERF_TIMER_START(write_pre_and_post_process_time);
|
2017-06-24 23:06:43 +02:00
|
|
|
}
|
|
|
|
log::Writer* log_writer = logs_.back().writer;
|
2017-04-06 02:14:05 +02:00
|
|
|
|
|
|
|
mutex_.Unlock();
|
|
|
|
|
|
|
|
// Add to log and apply to memtable. We can release the lock
|
|
|
|
// during this phase since &w is currently responsible for logging
|
|
|
|
// and protects against concurrent loggers and concurrent writes
|
|
|
|
// into memtables
|
|
|
|
|
2018-05-22 20:58:51 +02:00
|
|
|
TEST_SYNC_POINT("DBImpl::WriteImpl:BeforeLeaderEnters");
|
2017-04-06 02:14:05 +02:00
|
|
|
last_batch_group_size_ =
|
2017-05-19 23:24:23 +02:00
|
|
|
write_thread_.EnterAsBatchGroupLeader(&w, &write_group);
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2020-09-29 18:47:33 +02:00
|
|
|
IOStatus io_s;
|
2021-07-12 07:37:01 +02:00
|
|
|
Status pre_release_cb_status;
|
2017-04-06 02:14:05 +02:00
|
|
|
if (status.ok()) {
|
|
|
|
// Rules for when we can update the memtable concurrently
|
|
|
|
// 1. supported by memtable
|
|
|
|
// 2. Puts are not okay if inplace_update_support
|
2017-04-10 21:37:07 +02:00
|
|
|
// 3. Merges are not okay
|
2017-04-06 02:14:05 +02:00
|
|
|
//
|
2017-04-10 21:37:07 +02:00
|
|
|
// Rules 1..2 are enforced by checking the options
|
2017-04-06 02:14:05 +02:00
|
|
|
// during startup (CheckConcurrentWritesSupported), so if
|
|
|
|
// options.allow_concurrent_memtable_write is true then they can be
|
2017-04-10 21:37:07 +02:00
|
|
|
// assumed to be true. Rule 3 is checked for each batch. We could
|
|
|
|
// relax rules 2 if we could prevent write batches from referring
|
2017-04-06 02:14:05 +02:00
|
|
|
// more than once to a particular key.
|
|
|
|
bool parallel = immutable_db_options_.allow_concurrent_memtable_write &&
|
2017-05-19 23:24:23 +02:00
|
|
|
write_group.size > 1;
|
2017-09-18 23:36:53 +02:00
|
|
|
size_t total_count = 0;
|
2017-11-15 17:22:54 +01:00
|
|
|
size_t valid_batches = 0;
|
2018-03-06 21:27:07 +01:00
|
|
|
size_t total_byte_size = 0;
|
2019-06-10 20:47:16 +02:00
|
|
|
size_t pre_release_callback_cnt = 0;
|
2017-05-19 23:24:23 +02:00
|
|
|
for (auto* writer : write_group) {
|
2017-04-06 02:14:05 +02:00
|
|
|
if (writer->CheckCallback(this)) {
|
2018-02-06 03:32:54 +01:00
|
|
|
valid_batches += writer->batch_cnt;
|
2017-04-06 02:14:05 +02:00
|
|
|
if (writer->ShouldWriteToMemtable()) {
|
|
|
|
total_count += WriteBatchInternal::Count(writer->batch);
|
|
|
|
parallel = parallel && !writer->batch->HasMerge();
|
|
|
|
}
|
2017-04-13 20:58:44 +02:00
|
|
|
total_byte_size = WriteBatchInternal::AppendedByteSize(
|
|
|
|
total_byte_size, WriteBatchInternal::ByteSize(writer->batch));
|
2019-06-10 20:47:16 +02:00
|
|
|
if (writer->pre_release_callback) {
|
|
|
|
pre_release_callback_cnt++;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
}
|
2017-11-15 17:22:54 +01:00
|
|
|
// Note about seq_per_batch_: either disableWAL is set for the entire write
|
|
|
|
// group or not. In either case we inc seq for each write batch with no
|
|
|
|
// failed callback. This means that there could be a batch with
|
|
|
|
// disalbe_memtable in between; although we do not write this batch to
|
|
|
|
// memtable it still consumes a seq. Otherwise, if !seq_per_batch_, we inc
|
|
|
|
// the seq per valid written key to mem.
|
|
|
|
size_t seq_inc = seq_per_batch_ ? valid_batches : total_count;
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2017-11-11 02:18:01 +01:00
|
|
|
const bool concurrent_update = two_write_queues_;
|
2017-04-06 02:14:05 +02:00
|
|
|
// Update stats while we are an exclusive group leader, so we know
|
|
|
|
// that nobody else can be writing to these particular stats.
|
|
|
|
// We're optimistic, updating the stats before we successfully
|
2017-04-13 23:46:25 +02:00
|
|
|
// commit. That lets us release our leader status early.
|
2017-04-06 02:14:05 +02:00
|
|
|
auto stats = default_cf_internal_stats_;
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsNumKeysWritten, total_count,
|
2017-06-30 01:57:13 +02:00
|
|
|
concurrent_update);
|
2017-04-06 02:14:05 +02:00
|
|
|
RecordTick(stats_, NUMBER_KEYS_WRITTEN, total_count);
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsBytesWritten, total_byte_size,
|
2017-06-30 01:57:13 +02:00
|
|
|
concurrent_update);
|
2017-04-06 02:14:05 +02:00
|
|
|
RecordTick(stats_, BYTES_WRITTEN, total_byte_size);
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWriteDoneBySelf, 1,
|
|
|
|
concurrent_update);
|
2017-04-06 02:14:05 +02:00
|
|
|
RecordTick(stats_, WRITE_DONE_BY_SELF);
|
2017-05-19 23:24:23 +02:00
|
|
|
auto write_done_by_other = write_group.size - 1;
|
2017-04-06 02:14:05 +02:00
|
|
|
if (write_done_by_other > 0) {
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWriteDoneByOther,
|
|
|
|
write_done_by_other, concurrent_update);
|
2017-04-06 02:14:05 +02:00
|
|
|
RecordTick(stats_, WRITE_DONE_BY_OTHER, write_done_by_other);
|
|
|
|
}
|
2019-02-28 19:14:19 +01:00
|
|
|
RecordInHistogram(stats_, BYTES_PER_WRITE, total_byte_size);
|
2017-04-06 02:14:05 +02:00
|
|
|
|
|
|
|
if (write_options.disableWAL) {
|
|
|
|
has_unpersisted_data_.store(true, std::memory_order_relaxed);
|
|
|
|
}
|
|
|
|
|
|
|
|
PERF_TIMER_STOP(write_pre_and_post_process_time);
|
|
|
|
|
2017-11-11 02:18:01 +01:00
|
|
|
if (!two_write_queues_) {
|
2017-06-24 23:06:43 +02:00
|
|
|
if (status.ok() && !write_options.disableWAL) {
|
|
|
|
PERF_TIMER_GUARD(write_wal_time);
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
io_s = WriteToWAL(write_group, log_writer, log_used, need_log_sync,
|
|
|
|
need_log_dir_sync, last_sequence + 1);
|
2017-06-24 23:06:43 +02:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (status.ok() && !write_options.disableWAL) {
|
|
|
|
PERF_TIMER_GUARD(write_wal_time);
|
2017-11-11 02:18:01 +01:00
|
|
|
// LastAllocatedSequence is increased inside WriteToWAL under
|
2017-06-24 23:06:43 +02:00
|
|
|
// wal_write_mutex_ to ensure ordered events in WAL
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
io_s = ConcurrentWriteToWAL(write_group, log_used, &last_sequence,
|
|
|
|
seq_inc);
|
2017-06-24 23:06:43 +02:00
|
|
|
} else {
|
|
|
|
// Otherwise we inc seq number for memtable writes
|
2017-11-11 02:18:01 +01:00
|
|
|
last_sequence = versions_->FetchAddLastAllocatedSequence(seq_inc);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
}
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
status = io_s;
|
2017-06-29 00:36:11 +02:00
|
|
|
assert(last_sequence != kMaxSequenceNumber);
|
2017-06-24 23:06:43 +02:00
|
|
|
const SequenceNumber current_sequence = last_sequence + 1;
|
2017-09-18 23:36:53 +02:00
|
|
|
last_sequence += seq_inc;
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2019-03-01 00:45:48 +01:00
|
|
|
// PreReleaseCallback is called after WAL write and before memtable write
|
|
|
|
if (status.ok()) {
|
|
|
|
SequenceNumber next_sequence = current_sequence;
|
2019-06-10 20:47:16 +02:00
|
|
|
size_t index = 0;
|
2019-03-01 00:45:48 +01:00
|
|
|
// Note: the logic for advancing seq here must be consistent with the
|
|
|
|
// logic in WriteBatchInternal::InsertInto(write_group...) as well as
|
|
|
|
// with WriteBatchInternal::InsertInto(write_batch...) that is called on
|
|
|
|
// the merged batch during recovery from the WAL.
|
|
|
|
for (auto* writer : write_group) {
|
|
|
|
if (writer->CallbackFailed()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
writer->sequence = next_sequence;
|
|
|
|
if (writer->pre_release_callback) {
|
2019-04-03 00:14:41 +02:00
|
|
|
Status ws = writer->pre_release_callback->Callback(
|
2019-06-10 20:47:16 +02:00
|
|
|
writer->sequence, disable_memtable, writer->log_used, index++,
|
|
|
|
pre_release_callback_cnt);
|
2019-03-01 00:45:48 +01:00
|
|
|
if (!ws.ok()) {
|
2021-07-12 07:37:01 +02:00
|
|
|
status = pre_release_cb_status = ws;
|
2019-03-01 00:45:48 +01:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (seq_per_batch_) {
|
|
|
|
assert(writer->batch_cnt);
|
|
|
|
next_sequence += writer->batch_cnt;
|
|
|
|
} else if (writer->ShouldWriteToMemtable()) {
|
|
|
|
next_sequence += WriteBatchInternal::Count(writer->batch);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
if (status.ok()) {
|
|
|
|
PERF_TIMER_GUARD(write_memtable_time);
|
|
|
|
|
|
|
|
if (!parallel) {
|
2017-11-15 17:22:54 +01:00
|
|
|
// w.sequence will be set inside InsertInto
|
2017-04-13 23:46:25 +02:00
|
|
|
w.status = WriteBatchInternal::InsertInto(
|
2017-04-06 02:14:05 +02:00
|
|
|
write_group, current_sequence, column_family_memtables_.get(),
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
&flush_scheduler_, &trim_history_scheduler_,
|
|
|
|
write_options.ignore_missing_column_families,
|
2018-07-24 09:09:18 +02:00
|
|
|
0 /*recovery_log_number*/, this, parallel, seq_per_batch_,
|
|
|
|
batch_per_txn_);
|
2017-04-06 02:14:05 +02:00
|
|
|
} else {
|
2017-05-19 23:24:23 +02:00
|
|
|
write_group.last_sequence = last_sequence;
|
|
|
|
write_thread_.LaunchParallelMemTableWriters(&write_group);
|
2017-04-13 23:46:25 +02:00
|
|
|
in_parallel_group = true;
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2017-04-10 21:37:07 +02:00
|
|
|
// Each parallel follower is doing each own writes. The leader should
|
|
|
|
// also do its own.
|
2017-04-06 02:14:05 +02:00
|
|
|
if (w.ShouldWriteToMemtable()) {
|
|
|
|
ColumnFamilyMemTablesImpl column_family_memtables(
|
|
|
|
versions_->GetColumnFamilySet());
|
|
|
|
assert(w.sequence == current_sequence);
|
|
|
|
w.status = WriteBatchInternal::InsertInto(
|
2017-05-31 19:45:47 +02:00
|
|
|
&w, w.sequence, &column_family_memtables, &flush_scheduler_,
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
&trim_history_scheduler_,
|
2017-04-06 02:14:05 +02:00
|
|
|
write_options.ignore_missing_column_families, 0 /*log_number*/,
|
2018-02-06 03:32:54 +01:00
|
|
|
this, true /*concurrent_memtable_writes*/, seq_per_batch_,
|
2019-09-13 01:53:31 +02:00
|
|
|
w.batch_cnt, batch_per_txn_,
|
|
|
|
write_options.memtable_insert_hint_per_batch);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
2017-09-18 23:36:53 +02:00
|
|
|
}
|
|
|
|
if (seq_used != nullptr) {
|
|
|
|
*seq_used = w.sequence;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
PERF_TIMER_START(write_pre_and_post_process_time);
|
|
|
|
|
2017-05-19 23:24:23 +02:00
|
|
|
if (!w.CallbackFailed()) {
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
if (!io_s.ok()) {
|
2021-07-12 07:37:01 +02:00
|
|
|
assert(pre_release_cb_status.ok());
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
IOStatusCheck(io_s);
|
|
|
|
} else {
|
2021-07-12 07:37:01 +02:00
|
|
|
WriteStatusCheck(pre_release_cb_status);
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
}
|
2021-07-12 07:37:01 +02:00
|
|
|
} else {
|
|
|
|
assert(io_s.ok() && pre_release_cb_status.ok());
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
2017-05-19 23:24:23 +02:00
|
|
|
if (need_log_sync) {
|
2017-04-06 02:14:05 +02:00
|
|
|
mutex_.Lock();
|
2020-11-07 01:30:44 +01:00
|
|
|
if (status.ok()) {
|
|
|
|
status = MarkLogsSynced(logfile_number_, need_log_dir_sync);
|
|
|
|
} else {
|
|
|
|
MarkLogsNotSynced(logfile_number_);
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
mutex_.Unlock();
|
2017-11-11 02:18:01 +01:00
|
|
|
// Requesting sync with two_write_queues_ is expected to be very rare. We
|
2018-04-24 02:53:27 +02:00
|
|
|
// hence provide a simple implementation that is not necessarily efficient.
|
2017-11-11 02:18:01 +01:00
|
|
|
if (two_write_queues_) {
|
2017-06-24 23:06:43 +02:00
|
|
|
if (manual_wal_flush_) {
|
|
|
|
status = FlushWAL(true);
|
|
|
|
} else {
|
|
|
|
status = SyncWAL();
|
|
|
|
}
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
2017-04-13 23:46:25 +02:00
|
|
|
bool should_exit_batch_group = true;
|
|
|
|
if (in_parallel_group) {
|
|
|
|
// CompleteParallelWorker returns true if this thread should
|
|
|
|
// handle exit, false means somebody else did
|
2017-05-19 23:24:23 +02:00
|
|
|
should_exit_batch_group = write_thread_.CompleteParallelMemTableWriter(&w);
|
2017-04-13 23:46:25 +02:00
|
|
|
}
|
|
|
|
if (should_exit_batch_group) {
|
2017-06-24 23:06:43 +02:00
|
|
|
if (status.ok()) {
|
2019-03-01 00:45:48 +01:00
|
|
|
// Note: if we are to resume after non-OK statuses we need to revisit how
|
|
|
|
// we reacts to non-OK statuses here.
|
2017-06-24 23:06:43 +02:00
|
|
|
versions_->SetLastSequence(last_sequence);
|
|
|
|
}
|
2017-05-19 23:24:23 +02:00
|
|
|
MemTableInsertStatusCheck(w.status);
|
2017-11-28 20:40:40 +01:00
|
|
|
write_thread_.ExitAsBatchGroupLeader(write_group, status);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
2017-04-13 23:46:25 +02:00
|
|
|
if (status.ok()) {
|
|
|
|
status = w.FinalStatus();
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2017-05-19 23:24:23 +02:00
|
|
|
Status DBImpl::PipelinedWriteImpl(const WriteOptions& write_options,
|
|
|
|
WriteBatch* my_batch, WriteCallback* callback,
|
|
|
|
uint64_t* log_used, uint64_t log_ref,
|
2017-08-17 01:49:11 +02:00
|
|
|
bool disable_memtable, uint64_t* seq_used) {
|
2017-05-19 23:24:23 +02:00
|
|
|
PERF_TIMER_GUARD(write_pre_and_post_process_time);
|
2021-10-20 23:03:44 +02:00
|
|
|
StopWatch write_sw(immutable_db_options_.clock, stats_, DB_WRITE);
|
2017-05-19 23:24:23 +02:00
|
|
|
|
|
|
|
WriteContext write_context;
|
|
|
|
|
|
|
|
WriteThread::Writer w(write_options, my_batch, callback, log_ref,
|
|
|
|
disable_memtable);
|
|
|
|
write_thread_.JoinBatchGroup(&w);
|
2020-10-06 21:42:57 +02:00
|
|
|
TEST_SYNC_POINT("DBImplWrite::PipelinedWriteImpl:AfterJoinBatchGroup");
|
2017-05-19 23:24:23 +02:00
|
|
|
if (w.state == WriteThread::STATE_GROUP_LEADER) {
|
|
|
|
WriteThread::WriteGroup wal_write_group;
|
|
|
|
if (w.callback && !w.callback->AllowWriteBatching()) {
|
|
|
|
write_thread_.WaitForMemTableWriters();
|
|
|
|
}
|
|
|
|
mutex_.Lock();
|
|
|
|
bool need_log_sync = !write_options.disableWAL && write_options.sync;
|
|
|
|
bool need_log_dir_sync = need_log_sync && !log_dir_synced_;
|
2018-04-24 02:53:27 +02:00
|
|
|
// PreprocessWrite does its own perf timing.
|
|
|
|
PERF_TIMER_STOP(write_pre_and_post_process_time);
|
2017-05-19 23:24:23 +02:00
|
|
|
w.status = PreprocessWrite(write_options, &need_log_sync, &write_context);
|
2018-04-24 02:53:27 +02:00
|
|
|
PERF_TIMER_START(write_pre_and_post_process_time);
|
2017-06-24 23:06:43 +02:00
|
|
|
log::Writer* log_writer = logs_.back().writer;
|
2017-05-19 23:24:23 +02:00
|
|
|
mutex_.Unlock();
|
|
|
|
|
|
|
|
// This can set non-OK status if callback fail.
|
|
|
|
last_batch_group_size_ =
|
|
|
|
write_thread_.EnterAsBatchGroupLeader(&w, &wal_write_group);
|
|
|
|
const SequenceNumber current_sequence =
|
|
|
|
write_thread_.UpdateLastSequence(versions_->LastSequence()) + 1;
|
|
|
|
size_t total_count = 0;
|
|
|
|
size_t total_byte_size = 0;
|
|
|
|
|
|
|
|
if (w.status.ok()) {
|
|
|
|
SequenceNumber next_sequence = current_sequence;
|
|
|
|
for (auto writer : wal_write_group) {
|
|
|
|
if (writer->CheckCallback(this)) {
|
|
|
|
if (writer->ShouldWriteToMemtable()) {
|
|
|
|
writer->sequence = next_sequence;
|
|
|
|
size_t count = WriteBatchInternal::Count(writer->batch);
|
|
|
|
next_sequence += count;
|
|
|
|
total_count += count;
|
|
|
|
}
|
|
|
|
total_byte_size = WriteBatchInternal::AppendedByteSize(
|
|
|
|
total_byte_size, WriteBatchInternal::ByteSize(writer->batch));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (w.disable_wal) {
|
|
|
|
has_unpersisted_data_.store(true, std::memory_order_relaxed);
|
|
|
|
}
|
|
|
|
write_thread_.UpdateLastSequence(current_sequence + total_count - 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
auto stats = default_cf_internal_stats_;
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsNumKeysWritten, total_count);
|
2017-05-19 23:24:23 +02:00
|
|
|
RecordTick(stats_, NUMBER_KEYS_WRITTEN, total_count);
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsBytesWritten, total_byte_size);
|
2017-05-19 23:24:23 +02:00
|
|
|
RecordTick(stats_, BYTES_WRITTEN, total_byte_size);
|
2019-02-28 19:14:19 +01:00
|
|
|
RecordInHistogram(stats_, BYTES_PER_WRITE, total_byte_size);
|
2017-05-19 23:24:23 +02:00
|
|
|
|
|
|
|
PERF_TIMER_STOP(write_pre_and_post_process_time);
|
|
|
|
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
IOStatus io_s;
|
2020-12-23 08:44:44 +01:00
|
|
|
io_s.PermitUncheckedError(); // Allow io_s to be uninitialized
|
|
|
|
|
2019-01-03 21:36:43 +01:00
|
|
|
if (w.status.ok() && !write_options.disableWAL) {
|
2017-05-19 23:24:23 +02:00
|
|
|
PERF_TIMER_GUARD(write_wal_time);
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWriteDoneBySelf, 1);
|
2017-05-19 23:24:23 +02:00
|
|
|
RecordTick(stats_, WRITE_DONE_BY_SELF, 1);
|
|
|
|
if (wal_write_group.size > 1) {
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWriteDoneByOther,
|
2017-05-19 23:24:23 +02:00
|
|
|
wal_write_group.size - 1);
|
|
|
|
RecordTick(stats_, WRITE_DONE_BY_OTHER, wal_write_group.size - 1);
|
|
|
|
}
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
io_s = WriteToWAL(wal_write_group, log_writer, log_used, need_log_sync,
|
|
|
|
need_log_dir_sync, current_sequence);
|
|
|
|
w.status = io_s;
|
2017-05-19 23:24:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!w.CallbackFailed()) {
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
if (!io_s.ok()) {
|
|
|
|
IOStatusCheck(io_s);
|
|
|
|
} else {
|
|
|
|
WriteStatusCheck(w.status);
|
|
|
|
}
|
2017-05-19 23:24:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (need_log_sync) {
|
|
|
|
mutex_.Lock();
|
2020-11-07 01:30:44 +01:00
|
|
|
if (w.status.ok()) {
|
|
|
|
w.status = MarkLogsSynced(logfile_number_, need_log_dir_sync);
|
|
|
|
} else {
|
|
|
|
MarkLogsNotSynced(logfile_number_);
|
|
|
|
}
|
2017-05-19 23:24:23 +02:00
|
|
|
mutex_.Unlock();
|
|
|
|
}
|
|
|
|
|
|
|
|
write_thread_.ExitAsBatchGroupLeader(wal_write_group, w.status);
|
|
|
|
}
|
|
|
|
|
2020-12-23 00:08:17 +01:00
|
|
|
// NOTE: the memtable_write_group is declared before the following
|
|
|
|
// `if` statement because its lifetime needs to be longer
|
|
|
|
// that the inner context of the `if` as a reference to it
|
|
|
|
// may be used further below within the outer _write_thread
|
2017-05-19 23:24:23 +02:00
|
|
|
WriteThread::WriteGroup memtable_write_group;
|
2020-12-23 00:08:17 +01:00
|
|
|
|
2017-05-19 23:24:23 +02:00
|
|
|
if (w.state == WriteThread::STATE_MEMTABLE_WRITER_LEADER) {
|
|
|
|
PERF_TIMER_GUARD(write_memtable_time);
|
2019-01-03 21:36:43 +01:00
|
|
|
assert(w.ShouldWriteToMemtable());
|
2017-05-19 23:24:23 +02:00
|
|
|
write_thread_.EnterAsMemTableWriter(&w, &memtable_write_group);
|
|
|
|
if (memtable_write_group.size > 1 &&
|
|
|
|
immutable_db_options_.allow_concurrent_memtable_write) {
|
|
|
|
write_thread_.LaunchParallelMemTableWriters(&memtable_write_group);
|
|
|
|
} else {
|
|
|
|
memtable_write_group.status = WriteBatchInternal::InsertInto(
|
|
|
|
memtable_write_group, w.sequence, column_family_memtables_.get(),
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
&flush_scheduler_, &trim_history_scheduler_,
|
|
|
|
write_options.ignore_missing_column_families, 0 /*log_number*/, this,
|
|
|
|
false /*concurrent_memtable_writes*/, seq_per_batch_, batch_per_txn_);
|
2017-05-19 23:24:23 +02:00
|
|
|
versions_->SetLastSequence(memtable_write_group.last_sequence);
|
|
|
|
write_thread_.ExitAsMemTableWriter(&w, memtable_write_group);
|
|
|
|
}
|
2020-12-23 00:08:17 +01:00
|
|
|
} else {
|
|
|
|
// NOTE: the memtable_write_group is never really used,
|
|
|
|
// so we need to set its status to pass ASSERT_STATUS_CHECKED
|
|
|
|
memtable_write_group.status.PermitUncheckedError();
|
2017-05-19 23:24:23 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (w.state == WriteThread::STATE_PARALLEL_MEMTABLE_WRITER) {
|
|
|
|
assert(w.ShouldWriteToMemtable());
|
|
|
|
ColumnFamilyMemTablesImpl column_family_memtables(
|
|
|
|
versions_->GetColumnFamilySet());
|
|
|
|
w.status = WriteBatchInternal::InsertInto(
|
2017-05-31 19:45:47 +02:00
|
|
|
&w, w.sequence, &column_family_memtables, &flush_scheduler_,
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
&trim_history_scheduler_, write_options.ignore_missing_column_families,
|
2019-09-13 01:53:31 +02:00
|
|
|
0 /*log_number*/, this, true /*concurrent_memtable_writes*/,
|
|
|
|
false /*seq_per_batch*/, 0 /*batch_cnt*/, true /*batch_per_txn*/,
|
|
|
|
write_options.memtable_insert_hint_per_batch);
|
2017-05-19 23:24:23 +02:00
|
|
|
if (write_thread_.CompleteParallelMemTableWriter(&w)) {
|
|
|
|
MemTableInsertStatusCheck(w.status);
|
|
|
|
versions_->SetLastSequence(w.write_group->last_sequence);
|
|
|
|
write_thread_.ExitAsMemTableWriter(&w, *w.write_group);
|
|
|
|
}
|
|
|
|
}
|
2017-08-17 01:49:11 +02:00
|
|
|
if (seq_used != nullptr) {
|
|
|
|
*seq_used = w.sequence;
|
|
|
|
}
|
2017-05-19 23:24:23 +02:00
|
|
|
|
|
|
|
assert(w.state == WriteThread::STATE_COMPLETED);
|
2017-06-24 23:06:43 +02:00
|
|
|
return w.FinalStatus();
|
|
|
|
}
|
|
|
|
|
2019-05-14 02:43:47 +02:00
|
|
|
Status DBImpl::UnorderedWriteMemtable(const WriteOptions& write_options,
|
|
|
|
WriteBatch* my_batch,
|
|
|
|
WriteCallback* callback, uint64_t log_ref,
|
|
|
|
SequenceNumber seq,
|
|
|
|
const size_t sub_batch_cnt) {
|
|
|
|
PERF_TIMER_GUARD(write_pre_and_post_process_time);
|
2021-10-20 23:03:44 +02:00
|
|
|
StopWatch write_sw(immutable_db_options_.clock, stats_, DB_WRITE);
|
2019-05-14 02:43:47 +02:00
|
|
|
|
|
|
|
WriteThread::Writer w(write_options, my_batch, callback, log_ref,
|
|
|
|
false /*disable_memtable*/);
|
|
|
|
|
|
|
|
if (w.CheckCallback(this) && w.ShouldWriteToMemtable()) {
|
|
|
|
w.sequence = seq;
|
|
|
|
size_t total_count = WriteBatchInternal::Count(my_batch);
|
|
|
|
InternalStats* stats = default_cf_internal_stats_;
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsNumKeysWritten, total_count);
|
2019-05-14 02:43:47 +02:00
|
|
|
RecordTick(stats_, NUMBER_KEYS_WRITTEN, total_count);
|
|
|
|
|
|
|
|
ColumnFamilyMemTablesImpl column_family_memtables(
|
|
|
|
versions_->GetColumnFamilySet());
|
|
|
|
w.status = WriteBatchInternal::InsertInto(
|
|
|
|
&w, w.sequence, &column_family_memtables, &flush_scheduler_,
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
&trim_history_scheduler_, write_options.ignore_missing_column_families,
|
|
|
|
0 /*log_number*/, this, true /*concurrent_memtable_writes*/,
|
2019-09-13 01:53:31 +02:00
|
|
|
seq_per_batch_, sub_batch_cnt, true /*batch_per_txn*/,
|
|
|
|
write_options.memtable_insert_hint_per_batch);
|
2019-05-14 02:43:47 +02:00
|
|
|
if (write_options.disableWAL) {
|
|
|
|
has_unpersisted_data_.store(true, std::memory_order_relaxed);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t pending_cnt = pending_memtable_writes_.fetch_sub(1) - 1;
|
|
|
|
if (pending_cnt == 0) {
|
2019-05-20 16:46:15 +02:00
|
|
|
// switch_cv_ waits until pending_memtable_writes_ = 0. Locking its mutex
|
|
|
|
// before notify ensures that cv is in waiting state when it is notified
|
|
|
|
// thus not missing the update to pending_memtable_writes_ even though it is
|
|
|
|
// not modified under the mutex.
|
|
|
|
std::lock_guard<std::mutex> lck(switch_mutex_);
|
2019-05-14 02:43:47 +02:00
|
|
|
switch_cv_.notify_all();
|
|
|
|
}
|
2020-08-07 20:27:14 +02:00
|
|
|
WriteStatusCheck(w.status);
|
2019-05-14 02:43:47 +02:00
|
|
|
|
|
|
|
if (!w.FinalStatus().ok()) {
|
|
|
|
return w.FinalStatus();
|
|
|
|
}
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
2017-12-01 08:39:56 +01:00
|
|
|
// The 2nd write queue. If enabled it will be used only for WAL-only writes.
|
|
|
|
// This is the only queue that updates LastPublishedSequence which is only
|
|
|
|
// applicable in a two-queue setting.
|
2019-05-14 02:43:47 +02:00
|
|
|
Status DBImpl::WriteImplWALOnly(
|
|
|
|
WriteThread* write_thread, const WriteOptions& write_options,
|
|
|
|
WriteBatch* my_batch, WriteCallback* callback, uint64_t* log_used,
|
|
|
|
const uint64_t log_ref, uint64_t* seq_used, const size_t sub_batch_cnt,
|
|
|
|
PreReleaseCallback* pre_release_callback, const AssignOrder assign_order,
|
|
|
|
const PublishLastSeq publish_last_seq, const bool disable_memtable) {
|
2017-06-24 23:06:43 +02:00
|
|
|
PERF_TIMER_GUARD(write_pre_and_post_process_time);
|
|
|
|
WriteThread::Writer w(write_options, my_batch, callback, log_ref,
|
2019-05-14 02:43:47 +02:00
|
|
|
disable_memtable, sub_batch_cnt, pre_release_callback);
|
2021-10-20 23:03:44 +02:00
|
|
|
StopWatch write_sw(immutable_db_options_.clock, stats_, DB_WRITE);
|
2017-05-19 23:24:23 +02:00
|
|
|
|
2019-05-14 02:43:47 +02:00
|
|
|
write_thread->JoinBatchGroup(&w);
|
2017-06-24 23:06:43 +02:00
|
|
|
assert(w.state != WriteThread::STATE_PARALLEL_MEMTABLE_WRITER);
|
|
|
|
if (w.state == WriteThread::STATE_COMPLETED) {
|
|
|
|
if (log_used != nullptr) {
|
|
|
|
*log_used = w.log_used;
|
|
|
|
}
|
2017-08-17 01:49:11 +02:00
|
|
|
if (seq_used != nullptr) {
|
|
|
|
*seq_used = w.sequence;
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
return w.FinalStatus();
|
|
|
|
}
|
|
|
|
// else we are the leader of the write batch group
|
|
|
|
assert(w.state == WriteThread::STATE_GROUP_LEADER);
|
2019-05-14 02:43:47 +02:00
|
|
|
|
|
|
|
if (publish_last_seq == kDoPublishLastSeq) {
|
2020-12-10 06:19:55 +01:00
|
|
|
Status status;
|
|
|
|
|
2019-05-14 02:43:47 +02:00
|
|
|
// Currently we only use kDoPublishLastSeq in unordered_write
|
|
|
|
assert(immutable_db_options_.unordered_write);
|
|
|
|
WriteContext write_context;
|
|
|
|
if (error_handler_.IsDBStopped()) {
|
|
|
|
status = error_handler_.GetBGError();
|
|
|
|
}
|
|
|
|
// TODO(myabandeh): Make preliminary checks thread-safe so we could do them
|
|
|
|
// without paying the cost of obtaining the mutex.
|
|
|
|
if (status.ok()) {
|
|
|
|
InstrumentedMutexLock l(&mutex_);
|
|
|
|
bool need_log_sync = false;
|
|
|
|
status = PreprocessWrite(write_options, &need_log_sync, &write_context);
|
2020-08-07 20:27:14 +02:00
|
|
|
WriteStatusCheckOnLocked(status);
|
2019-05-14 02:43:47 +02:00
|
|
|
}
|
|
|
|
if (!status.ok()) {
|
|
|
|
WriteThread::WriteGroup write_group;
|
|
|
|
write_thread->EnterAsBatchGroupLeader(&w, &write_group);
|
|
|
|
write_thread->ExitAsBatchGroupLeader(write_group, status);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-24 23:06:43 +02:00
|
|
|
WriteThread::WriteGroup write_group;
|
|
|
|
uint64_t last_sequence;
|
2019-05-14 02:43:47 +02:00
|
|
|
write_thread->EnterAsBatchGroupLeader(&w, &write_group);
|
2017-06-24 23:06:43 +02:00
|
|
|
// Note: no need to update last_batch_group_size_ here since the batch writes
|
|
|
|
// to WAL only
|
|
|
|
|
2019-06-10 20:47:16 +02:00
|
|
|
size_t pre_release_callback_cnt = 0;
|
2018-03-06 21:27:07 +01:00
|
|
|
size_t total_byte_size = 0;
|
2017-06-24 23:06:43 +02:00
|
|
|
for (auto* writer : write_group) {
|
|
|
|
if (writer->CheckCallback(this)) {
|
|
|
|
total_byte_size = WriteBatchInternal::AppendedByteSize(
|
|
|
|
total_byte_size, WriteBatchInternal::ByteSize(writer->batch));
|
2019-06-10 20:47:16 +02:00
|
|
|
if (writer->pre_release_callback) {
|
|
|
|
pre_release_callback_cnt++;
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-30 01:57:13 +02:00
|
|
|
const bool concurrent_update = true;
|
2017-06-24 23:06:43 +02:00
|
|
|
// Update stats while we are an exclusive group leader, so we know
|
|
|
|
// that nobody else can be writing to these particular stats.
|
|
|
|
// We're optimistic, updating the stats before we successfully
|
|
|
|
// commit. That lets us release our leader status early.
|
|
|
|
auto stats = default_cf_internal_stats_;
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsBytesWritten, total_byte_size,
|
2017-06-30 01:57:13 +02:00
|
|
|
concurrent_update);
|
2017-06-24 23:06:43 +02:00
|
|
|
RecordTick(stats_, BYTES_WRITTEN, total_byte_size);
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWriteDoneBySelf, 1,
|
|
|
|
concurrent_update);
|
2017-06-24 23:06:43 +02:00
|
|
|
RecordTick(stats_, WRITE_DONE_BY_SELF);
|
|
|
|
auto write_done_by_other = write_group.size - 1;
|
|
|
|
if (write_done_by_other > 0) {
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWriteDoneByOther,
|
|
|
|
write_done_by_other, concurrent_update);
|
2017-06-24 23:06:43 +02:00
|
|
|
RecordTick(stats_, WRITE_DONE_BY_OTHER, write_done_by_other);
|
|
|
|
}
|
2019-02-28 19:14:19 +01:00
|
|
|
RecordInHistogram(stats_, BYTES_PER_WRITE, total_byte_size);
|
2017-06-24 23:06:43 +02:00
|
|
|
|
|
|
|
PERF_TIMER_STOP(write_pre_and_post_process_time);
|
|
|
|
|
|
|
|
PERF_TIMER_GUARD(write_wal_time);
|
2017-11-11 02:18:01 +01:00
|
|
|
// LastAllocatedSequence is increased inside WriteToWAL under
|
2017-06-24 23:06:43 +02:00
|
|
|
// wal_write_mutex_ to ensure ordered events in WAL
|
2018-02-06 03:32:54 +01:00
|
|
|
size_t seq_inc = 0 /* total_count */;
|
2019-05-14 02:43:47 +02:00
|
|
|
if (assign_order == kDoAssignOrder) {
|
2018-02-06 03:32:54 +01:00
|
|
|
size_t total_batch_cnt = 0;
|
|
|
|
for (auto* writer : write_group) {
|
2019-05-14 02:43:47 +02:00
|
|
|
assert(writer->batch_cnt || !seq_per_batch_);
|
|
|
|
if (!writer->CallbackFailed()) {
|
|
|
|
total_batch_cnt += writer->batch_cnt;
|
|
|
|
}
|
2018-02-06 03:32:54 +01:00
|
|
|
}
|
|
|
|
seq_inc = total_batch_cnt;
|
|
|
|
}
|
2020-12-10 06:19:55 +01:00
|
|
|
Status status;
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
IOStatus io_s;
|
2020-12-23 08:44:44 +01:00
|
|
|
io_s.PermitUncheckedError(); // Allow io_s to be uninitialized
|
2017-12-13 16:55:02 +01:00
|
|
|
if (!write_options.disableWAL) {
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
io_s = ConcurrentWriteToWAL(write_group, log_used, &last_sequence, seq_inc);
|
|
|
|
status = io_s;
|
2017-12-13 16:55:02 +01:00
|
|
|
} else {
|
|
|
|
// Otherwise we inc seq number to do solely the seq allocation
|
|
|
|
last_sequence = versions_->FetchAddLastAllocatedSequence(seq_inc);
|
|
|
|
}
|
2019-05-14 02:43:47 +02:00
|
|
|
|
|
|
|
size_t memtable_write_cnt = 0;
|
2017-08-17 01:49:11 +02:00
|
|
|
auto curr_seq = last_sequence + 1;
|
|
|
|
for (auto* writer : write_group) {
|
2017-11-15 17:22:54 +01:00
|
|
|
if (writer->CallbackFailed()) {
|
|
|
|
continue;
|
2017-09-18 23:36:53 +02:00
|
|
|
}
|
2017-11-15 17:22:54 +01:00
|
|
|
writer->sequence = curr_seq;
|
2019-05-14 02:43:47 +02:00
|
|
|
if (assign_order == kDoAssignOrder) {
|
|
|
|
assert(writer->batch_cnt || !seq_per_batch_);
|
2018-02-06 03:32:54 +01:00
|
|
|
curr_seq += writer->batch_cnt;
|
2017-08-17 01:49:11 +02:00
|
|
|
}
|
2019-05-14 02:43:47 +02:00
|
|
|
if (!writer->disable_memtable) {
|
|
|
|
memtable_write_cnt++;
|
|
|
|
}
|
2017-11-15 17:22:54 +01:00
|
|
|
// else seq advances only by memtable writes
|
2017-08-17 01:49:11 +02:00
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
if (status.ok() && write_options.sync) {
|
2017-12-13 16:55:02 +01:00
|
|
|
assert(!write_options.disableWAL);
|
2017-11-11 02:18:01 +01:00
|
|
|
// Requesting sync with two_write_queues_ is expected to be very rare. We
|
2017-06-24 23:06:43 +02:00
|
|
|
// hance provide a simple implementation that is not necessarily efficient.
|
|
|
|
if (manual_wal_flush_) {
|
|
|
|
status = FlushWAL(true);
|
|
|
|
} else {
|
|
|
|
status = SyncWAL();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
PERF_TIMER_START(write_pre_and_post_process_time);
|
|
|
|
|
|
|
|
if (!w.CallbackFailed()) {
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
if (!io_s.ok()) {
|
|
|
|
IOStatusCheck(io_s);
|
|
|
|
} else {
|
|
|
|
WriteStatusCheck(status);
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
}
|
2017-12-01 08:39:56 +01:00
|
|
|
if (status.ok()) {
|
2019-06-10 20:47:16 +02:00
|
|
|
size_t index = 0;
|
2017-12-01 08:39:56 +01:00
|
|
|
for (auto* writer : write_group) {
|
|
|
|
if (!writer->CallbackFailed() && writer->pre_release_callback) {
|
|
|
|
assert(writer->sequence != kMaxSequenceNumber);
|
2019-04-03 00:14:41 +02:00
|
|
|
Status ws = writer->pre_release_callback->Callback(
|
2019-06-10 20:47:16 +02:00
|
|
|
writer->sequence, disable_memtable, writer->log_used, index++,
|
|
|
|
pre_release_callback_cnt);
|
2017-12-01 08:39:56 +01:00
|
|
|
if (!ws.ok()) {
|
|
|
|
status = ws;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-05-14 02:43:47 +02:00
|
|
|
if (publish_last_seq == kDoPublishLastSeq) {
|
|
|
|
versions_->SetLastSequence(last_sequence + seq_inc);
|
|
|
|
// Currently we only use kDoPublishLastSeq in unordered_write
|
|
|
|
assert(immutable_db_options_.unordered_write);
|
|
|
|
}
|
|
|
|
if (immutable_db_options_.unordered_write && status.ok()) {
|
|
|
|
pending_memtable_writes_ += memtable_write_cnt;
|
|
|
|
}
|
|
|
|
write_thread->ExitAsBatchGroupLeader(write_group, status);
|
2017-06-24 23:06:43 +02:00
|
|
|
if (status.ok()) {
|
|
|
|
status = w.FinalStatus();
|
|
|
|
}
|
2017-08-17 01:49:11 +02:00
|
|
|
if (seq_used != nullptr) {
|
|
|
|
*seq_used = w.sequence;
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
return status;
|
2017-05-19 23:24:23 +02:00
|
|
|
}
|
|
|
|
|
2020-08-07 20:27:14 +02:00
|
|
|
void DBImpl::WriteStatusCheckOnLocked(const Status& status) {
|
|
|
|
// Is setting bg_error_ enough here? This will at least stop
|
|
|
|
// compaction and fail any further writes.
|
|
|
|
// Caller must hold mutex_.
|
2020-09-15 01:03:32 +02:00
|
|
|
assert(!status.IsIOFenced() || !error_handler_.GetBGError().ok());
|
2020-08-07 20:27:14 +02:00
|
|
|
mutex_.AssertHeld();
|
|
|
|
if (immutable_db_options_.paranoid_checks && !status.ok() &&
|
|
|
|
!status.IsBusy() && !status.IsIncomplete()) {
|
2020-10-03 01:39:17 +02:00
|
|
|
// Maybe change the return status to void?
|
2020-12-08 05:09:55 +01:00
|
|
|
error_handler_.SetBGError(status, BackgroundErrorReason::kWriteCallback);
|
2020-08-07 20:27:14 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-03-22 23:56:52 +01:00
|
|
|
void DBImpl::WriteStatusCheck(const Status& status) {
|
2017-05-19 23:24:23 +02:00
|
|
|
// Is setting bg_error_ enough here? This will at least stop
|
|
|
|
// compaction and fail any further writes.
|
2020-09-15 01:03:32 +02:00
|
|
|
assert(!status.IsIOFenced() || !error_handler_.GetBGError().ok());
|
2017-05-19 23:24:23 +02:00
|
|
|
if (immutable_db_options_.paranoid_checks && !status.ok() &&
|
|
|
|
!status.IsBusy() && !status.IsIncomplete()) {
|
|
|
|
mutex_.Lock();
|
2020-10-03 01:39:17 +02:00
|
|
|
// Maybe change the return status to void?
|
2020-12-08 05:09:55 +01:00
|
|
|
error_handler_.SetBGError(status, BackgroundErrorReason::kWriteCallback);
|
2017-05-19 23:24:23 +02:00
|
|
|
mutex_.Unlock();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
void DBImpl::IOStatusCheck(const IOStatus& io_status) {
|
|
|
|
// Is setting bg_error_ enough here? This will at least stop
|
|
|
|
// compaction and fail any further writes.
|
2020-09-15 01:03:32 +02:00
|
|
|
if ((immutable_db_options_.paranoid_checks && !io_status.ok() &&
|
|
|
|
!io_status.IsBusy() && !io_status.IsIncomplete()) ||
|
|
|
|
io_status.IsIOFenced()) {
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
mutex_.Lock();
|
2020-10-03 01:39:17 +02:00
|
|
|
// Maybe change the return status to void?
|
2020-12-08 05:09:55 +01:00
|
|
|
error_handler_.SetBGError(io_status, BackgroundErrorReason::kWriteCallback);
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
mutex_.Unlock();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-19 23:24:23 +02:00
|
|
|
void DBImpl::MemTableInsertStatusCheck(const Status& status) {
|
2017-04-13 23:46:25 +02:00
|
|
|
// A non-OK status here indicates that the state implied by the
|
|
|
|
// WAL has diverged from the in-memory state. This could be
|
|
|
|
// because of a corrupt write_batch (very bad), or because the
|
|
|
|
// client specified an invalid column family and didn't specify
|
|
|
|
// ignore_missing_column_families.
|
2017-05-19 23:24:23 +02:00
|
|
|
if (!status.ok()) {
|
2017-04-13 23:46:25 +02:00
|
|
|
mutex_.Lock();
|
2018-06-28 21:23:57 +02:00
|
|
|
assert(!error_handler_.IsBGWorkStopped());
|
2020-10-03 01:39:17 +02:00
|
|
|
// Maybe change the return status to void?
|
2020-10-02 22:33:50 +02:00
|
|
|
error_handler_.SetBGError(status, BackgroundErrorReason::kMemTable)
|
|
|
|
.PermitUncheckedError();
|
2017-04-13 23:46:25 +02:00
|
|
|
mutex_.Unlock();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
Status DBImpl::PreprocessWrite(const WriteOptions& write_options,
|
2017-05-19 23:24:23 +02:00
|
|
|
bool* need_log_sync,
|
2017-04-06 02:14:05 +02:00
|
|
|
WriteContext* write_context) {
|
|
|
|
mutex_.AssertHeld();
|
2017-05-19 23:24:23 +02:00
|
|
|
assert(write_context != nullptr && need_log_sync != nullptr);
|
2017-04-06 02:14:05 +02:00
|
|
|
Status status;
|
|
|
|
|
Auto recovery from out of space errors (#4164)
Summary:
This commit implements automatic recovery from a Status::NoSpace() error
during background operations such as write callback, flush and
compaction. The broad design is as follows -
1. Compaction errors are treated as soft errors and don't put the
database in read-only mode. A compaction is delayed until enough free
disk space is available to accomodate the compaction outputs, which is
estimated based on the input size. This means that users can continue to
write, and we rely on the WriteController to delay or stop writes if the
compaction debt becomes too high due to persistent low disk space
condition
2. Errors during write callback and flush are treated as hard errors,
i.e the database is put in read-only mode and goes back to read-write
only fater certain recovery actions are taken.
3. Both types of recovery rely on the SstFileManagerImpl to poll for
sufficient disk space. We assume that there is a 1-1 mapping between an
SFM and the underlying OS storage container. For cases where multiple
DBs are hosted on a single storage container, the user is expected to
allocate a single SFM instance and use the same one for all the DBs. If
no SFM is specified by the user, DBImpl::Open() will allocate one, but
this will be one per DB and each DB will recover independently. The
recovery implemented by SFM is as follows -
a) On the first occurance of an out of space error during compaction,
subsequent
compactions will be delayed until the disk free space check indicates
enough available space. The required space is computed as the sum of
input sizes.
b) The free space check requirement will be removed once the amount of
free space is greater than the size reserved by in progress
compactions when the first error occured
c) If the out of space error is a hard error, a background thread in
SFM will poll for sufficient headroom before triggering the recovery
of the database and putting it in write-only mode. The headroom is
calculated as the sum of the write_buffer_size of all the DB instances
associated with the SFM
4. EventListener callbacks will be called at the start and completion of
automatic recovery. Users can disable the auto recov ery in the start
callback, and later initiate it manually by calling DB::Resume()
Todo:
1. More extensive testing
2. Add disk full condition to db_stress (follow-on PR)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4164
Differential Revision: D9846378
Pulled By: anand1976
fbshipit-source-id: 80ea875dbd7f00205e19c82215ff6e37da10da4a
2018-09-15 22:36:19 +02:00
|
|
|
if (error_handler_.IsDBStopped()) {
|
|
|
|
status = error_handler_.GetBGError();
|
|
|
|
}
|
|
|
|
|
2018-04-24 02:53:27 +02:00
|
|
|
PERF_TIMER_GUARD(write_scheduling_flushes_compactions_time);
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
assert(!single_column_family_mode_ ||
|
|
|
|
versions_->GetColumnFamilySet()->NumberOfColumnFamilies() == 1);
|
|
|
|
if (UNLIKELY(status.ok() && !single_column_family_mode_ &&
|
|
|
|
total_log_size_ > GetMaxTotalWalSize())) {
|
2019-05-14 02:43:47 +02:00
|
|
|
WaitForPendingWrites();
|
2017-09-28 02:37:08 +02:00
|
|
|
status = SwitchWAL(write_context);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
if (UNLIKELY(status.ok() && write_buffer_manager_->ShouldFlush())) {
|
|
|
|
// Before a new memtable is added in SwitchMemtable(),
|
|
|
|
// write_buffer_manager_->ShouldFlush() will keep returning true. If another
|
|
|
|
// thread is writing to another DB with the same write buffer, they may also
|
|
|
|
// be flushed. We may end up with flushing much more DBs than needed. It's
|
|
|
|
// suboptimal but still correct.
|
2019-05-14 02:43:47 +02:00
|
|
|
WaitForPendingWrites();
|
2021-04-08 08:17:41 +02:00
|
|
|
status = HandleWriteBufferManagerFlush(write_context);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
if (UNLIKELY(status.ok() && !trim_history_scheduler_.Empty())) {
|
|
|
|
status = TrimMemtableHistory(write_context);
|
|
|
|
}
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
if (UNLIKELY(status.ok() && !flush_scheduler_.Empty())) {
|
2019-05-14 02:43:47 +02:00
|
|
|
WaitForPendingWrites();
|
2017-04-06 02:14:05 +02:00
|
|
|
status = ScheduleFlushes(write_context);
|
|
|
|
}
|
|
|
|
|
2018-04-24 02:53:27 +02:00
|
|
|
PERF_TIMER_STOP(write_scheduling_flushes_compactions_time);
|
|
|
|
PERF_TIMER_GUARD(write_pre_and_post_process_time);
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
if (UNLIKELY(status.ok() && (write_controller_.IsStopped() ||
|
|
|
|
write_controller_.NeedsDelay()))) {
|
2018-04-24 02:53:27 +02:00
|
|
|
PERF_TIMER_STOP(write_pre_and_post_process_time);
|
2017-04-06 02:14:05 +02:00
|
|
|
PERF_TIMER_GUARD(write_delay_time);
|
|
|
|
// We don't know size of curent batch so that we always use the size
|
|
|
|
// for previous one. It might create a fairness issue that expiration
|
|
|
|
// might happen for smaller writes but larger writes can go through.
|
|
|
|
// Can optimize it if it is an issue.
|
|
|
|
status = DelayWrite(last_batch_group_size_, write_options);
|
2018-04-24 02:53:27 +02:00
|
|
|
PERF_TIMER_START(write_pre_and_post_process_time);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
2021-04-21 22:53:05 +02:00
|
|
|
// If memory usage exceeded beyond a certain threshold,
|
|
|
|
// write_buffer_manager_->ShouldStall() returns true to all threads writing to
|
|
|
|
// all DBs and writers will be stalled.
|
|
|
|
// It does soft checking because WriteBufferManager::buffer_limit_ has already
|
|
|
|
// exceeded at this point so no new write (including current one) will go
|
|
|
|
// through until memory usage is decreased.
|
|
|
|
if (UNLIKELY(status.ok() && write_buffer_manager_->ShouldStall())) {
|
|
|
|
if (write_options.no_slowdown) {
|
|
|
|
status = Status::Incomplete("Write stall");
|
|
|
|
} else {
|
|
|
|
WriteBufferManagerStallWrites();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-19 23:24:23 +02:00
|
|
|
if (status.ok() && *need_log_sync) {
|
2017-04-10 21:37:07 +02:00
|
|
|
// Wait until the parallel syncs are finished. Any sync process has to sync
|
|
|
|
// the front log too so it is enough to check the status of front()
|
|
|
|
// We do a while loop since log_sync_cv_ is signalled when any sync is
|
|
|
|
// finished
|
|
|
|
// Note: there does not seem to be a reason to wait for parallel sync at
|
|
|
|
// this early step but it is not important since parallel sync (SyncWAL) and
|
|
|
|
// need_log_sync are usually not used together.
|
2017-04-06 02:14:05 +02:00
|
|
|
while (logs_.front().getting_synced) {
|
|
|
|
log_sync_cv_.Wait();
|
|
|
|
}
|
|
|
|
for (auto& log : logs_) {
|
|
|
|
assert(!log.getting_synced);
|
2017-04-10 21:37:07 +02:00
|
|
|
// This is just to prevent the logs to be synced by a parallel SyncWAL
|
|
|
|
// call. We will do the actual syncing later after we will write to the
|
|
|
|
// WAL.
|
|
|
|
// Note: there does not seem to be a reason to set this early before we
|
|
|
|
// actually write to the WAL
|
2017-04-06 02:14:05 +02:00
|
|
|
log.getting_synced = true;
|
|
|
|
}
|
2017-05-19 23:24:23 +02:00
|
|
|
} else {
|
|
|
|
*need_log_sync = false;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2017-06-24 23:06:43 +02:00
|
|
|
WriteBatch* DBImpl::MergeBatch(const WriteThread::WriteGroup& write_group,
|
2017-11-02 01:23:52 +01:00
|
|
|
WriteBatch* tmp_batch, size_t* write_with_wal,
|
|
|
|
WriteBatch** to_be_cached_state) {
|
2017-06-24 23:06:43 +02:00
|
|
|
assert(write_with_wal != nullptr);
|
|
|
|
assert(tmp_batch != nullptr);
|
2017-11-02 01:23:52 +01:00
|
|
|
assert(*to_be_cached_state == nullptr);
|
2017-04-06 02:14:05 +02:00
|
|
|
WriteBatch* merged_batch = nullptr;
|
2017-06-24 23:06:43 +02:00
|
|
|
*write_with_wal = 0;
|
2017-05-19 23:24:23 +02:00
|
|
|
auto* leader = write_group.leader;
|
2017-11-15 17:22:54 +01:00
|
|
|
assert(!leader->disable_wal); // Same holds for all in the batch group
|
|
|
|
if (write_group.size == 1 && !leader->CallbackFailed() &&
|
2017-05-19 23:24:23 +02:00
|
|
|
leader->batch->GetWalTerminationPoint().is_cleared()) {
|
2017-04-06 02:14:05 +02:00
|
|
|
// we simply write the first WriteBatch to WAL if the group only
|
|
|
|
// contains one batch, that batch should be written to the WAL,
|
|
|
|
// and the batch is not wanting to be truncated
|
2017-05-19 23:24:23 +02:00
|
|
|
merged_batch = leader->batch;
|
2017-11-02 01:23:52 +01:00
|
|
|
if (WriteBatchInternal::IsLatestPersistentState(merged_batch)) {
|
|
|
|
*to_be_cached_state = merged_batch;
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
*write_with_wal = 1;
|
2017-04-06 02:14:05 +02:00
|
|
|
} else {
|
|
|
|
// WAL needs all of the batches flattened into a single batch.
|
|
|
|
// We could avoid copying here with an iov-like AddRecord
|
|
|
|
// interface
|
2017-06-24 23:06:43 +02:00
|
|
|
merged_batch = tmp_batch;
|
2017-04-06 02:14:05 +02:00
|
|
|
for (auto writer : write_group) {
|
2017-11-15 17:22:54 +01:00
|
|
|
if (!writer->CallbackFailed()) {
|
2020-10-03 07:09:28 +02:00
|
|
|
Status s = WriteBatchInternal::Append(merged_batch, writer->batch,
|
|
|
|
/*WAL_only*/ true);
|
|
|
|
// Always returns Status::OK.
|
|
|
|
assert(s.ok());
|
2017-11-02 01:23:52 +01:00
|
|
|
if (WriteBatchInternal::IsLatestPersistentState(writer->batch)) {
|
|
|
|
// We only need to cache the last of such write batch
|
|
|
|
*to_be_cached_state = writer->batch;
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
(*write_with_wal)++;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
return merged_batch;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2017-11-11 02:18:01 +01:00
|
|
|
// When two_write_queues_ is disabled, this function is called from the only
|
2017-06-30 18:30:03 +02:00
|
|
|
// write thread. Otherwise this must be called holding log_write_mutex_.
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
IOStatus DBImpl::WriteToWAL(const WriteBatch& merged_batch,
|
|
|
|
log::Writer* log_writer, uint64_t* log_used,
|
|
|
|
uint64_t* log_size) {
|
2017-06-24 23:06:43 +02:00
|
|
|
assert(log_size != nullptr);
|
|
|
|
Slice log_entry = WriteBatchInternal::Contents(&merged_batch);
|
|
|
|
*log_size = log_entry.size();
|
2018-03-27 01:16:59 +02:00
|
|
|
// When two_write_queues_ WriteToWAL has to be protected from concurretn calls
|
|
|
|
// from the two queues anyway and log_write_mutex_ is already held. Otherwise
|
|
|
|
// if manual_wal_flush_ is enabled we need to protect log_writer->AddRecord
|
|
|
|
// from possible concurrent calls via the FlushWAL by the application.
|
|
|
|
const bool needs_locking = manual_wal_flush_ && !two_write_queues_;
|
|
|
|
// Due to performance cocerns of missed branch prediction penalize the new
|
|
|
|
// manual_wal_flush_ feature (by UNLIKELY) instead of the more common case
|
|
|
|
// when we do not need any locking.
|
|
|
|
if (UNLIKELY(needs_locking)) {
|
|
|
|
log_write_mutex_.Lock();
|
|
|
|
}
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
IOStatus io_s = log_writer->AddRecord(log_entry);
|
|
|
|
|
2018-03-27 01:16:59 +02:00
|
|
|
if (UNLIKELY(needs_locking)) {
|
|
|
|
log_write_mutex_.Unlock();
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
if (log_used != nullptr) {
|
|
|
|
*log_used = logfile_number_;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
total_log_size_ += log_entry.size();
|
2017-06-30 18:30:03 +02:00
|
|
|
// TODO(myabandeh): it might be unsafe to access alive_log_files_.back() here
|
|
|
|
// since alive_log_files_ might be modified concurrently
|
2017-04-06 02:14:05 +02:00
|
|
|
alive_log_files_.back().AddSize(log_entry.size());
|
|
|
|
log_empty_ = false;
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
return io_s;
|
2017-06-24 23:06:43 +02:00
|
|
|
}
|
|
|
|
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
IOStatus DBImpl::WriteToWAL(const WriteThread::WriteGroup& write_group,
|
|
|
|
log::Writer* log_writer, uint64_t* log_used,
|
|
|
|
bool need_log_sync, bool need_log_dir_sync,
|
|
|
|
SequenceNumber sequence) {
|
|
|
|
IOStatus io_s;
|
2017-11-15 17:22:54 +01:00
|
|
|
assert(!write_group.leader->disable_wal);
|
|
|
|
// Same holds for all in the batch group
|
2017-06-24 23:06:43 +02:00
|
|
|
size_t write_with_wal = 0;
|
2017-11-02 01:23:52 +01:00
|
|
|
WriteBatch* to_be_cached_state = nullptr;
|
|
|
|
WriteBatch* merged_batch = MergeBatch(write_group, &tmp_batch_,
|
|
|
|
&write_with_wal, &to_be_cached_state);
|
2017-06-28 22:05:52 +02:00
|
|
|
if (merged_batch == write_group.leader->batch) {
|
|
|
|
write_group.leader->log_used = logfile_number_;
|
|
|
|
} else if (write_with_wal > 1) {
|
|
|
|
for (auto writer : write_group) {
|
|
|
|
writer->log_used = logfile_number_;
|
|
|
|
}
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
|
|
|
|
WriteBatchInternal::SetSequence(merged_batch, sequence);
|
|
|
|
|
|
|
|
uint64_t log_size;
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
io_s = WriteToWAL(*merged_batch, log_writer, log_used, &log_size);
|
2017-11-02 01:23:52 +01:00
|
|
|
if (to_be_cached_state) {
|
|
|
|
cached_recoverable_state_ = *to_be_cached_state;
|
2019-03-28 00:13:08 +01:00
|
|
|
cached_recoverable_state_empty_ = false;
|
2017-11-02 01:23:52 +01:00
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
if (io_s.ok() && need_log_sync) {
|
2021-03-15 12:32:24 +01:00
|
|
|
StopWatch sw(immutable_db_options_.clock, stats_, WAL_FILE_SYNC_MICROS);
|
2017-04-06 02:14:05 +02:00
|
|
|
// It's safe to access logs_ with unlocked mutex_ here because:
|
|
|
|
// - we've set getting_synced=true for all logs,
|
|
|
|
// so other threads won't pop from logs_ while we're here,
|
|
|
|
// - only writer thread can push to logs_, and we're in
|
|
|
|
// writer thread, so no one will push to logs_,
|
|
|
|
// - as long as other threads don't modify it, it's safe to read
|
|
|
|
// from std::deque from multiple threads concurrently.
|
2021-09-14 05:15:00 +02:00
|
|
|
//
|
|
|
|
// Sync operation should work with locked log_write_mutex_, because:
|
|
|
|
// when DBOptions.manual_wal_flush_ is set,
|
|
|
|
// FlushWAL function will be invoked by another thread.
|
|
|
|
// if without locked log_write_mutex_, the log file may get data
|
|
|
|
// corruption
|
|
|
|
|
|
|
|
const bool needs_locking = manual_wal_flush_ && !two_write_queues_;
|
|
|
|
if (UNLIKELY(needs_locking)) {
|
|
|
|
log_write_mutex_.Lock();
|
|
|
|
}
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
for (auto& log : logs_) {
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
io_s = log.writer->file()->Sync(immutable_db_options_.use_fsync);
|
|
|
|
if (!io_s.ok()) {
|
2017-04-06 02:14:05 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
|
2021-09-14 05:15:00 +02:00
|
|
|
if (UNLIKELY(needs_locking)) {
|
|
|
|
log_write_mutex_.Unlock();
|
|
|
|
}
|
|
|
|
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
if (io_s.ok() && need_log_dir_sync) {
|
2017-04-06 02:14:05 +02:00
|
|
|
// We only sync WAL directory the first time WAL syncing is
|
|
|
|
// requested, so that in case users never turn on WAL sync,
|
|
|
|
// we can avoid the disk I/O in the write code path.
|
2021-11-03 20:20:19 +01:00
|
|
|
io_s = directories_.GetWalDir()->FsyncWithDirOptions(
|
|
|
|
IOOptions(), nullptr,
|
|
|
|
DirFsyncOptions(DirFsyncOptions::FsyncReason::kNewFileSynced));
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (merged_batch == &tmp_batch_) {
|
|
|
|
tmp_batch_.Clear();
|
|
|
|
}
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
if (io_s.ok()) {
|
2017-04-06 02:14:05 +02:00
|
|
|
auto stats = default_cf_internal_stats_;
|
|
|
|
if (need_log_sync) {
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWalFileSynced, 1);
|
2017-04-06 02:14:05 +02:00
|
|
|
RecordTick(stats_, WAL_FILE_SYNCED);
|
|
|
|
}
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWalFileBytes, log_size);
|
2017-04-06 02:14:05 +02:00
|
|
|
RecordTick(stats_, WAL_FILE_BYTES, log_size);
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWriteWithWal, write_with_wal);
|
2017-04-06 02:14:05 +02:00
|
|
|
RecordTick(stats_, WRITE_WITH_WAL, write_with_wal);
|
|
|
|
}
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
return io_s;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
IOStatus DBImpl::ConcurrentWriteToWAL(
|
|
|
|
const WriteThread::WriteGroup& write_group, uint64_t* log_used,
|
|
|
|
SequenceNumber* last_sequence, size_t seq_inc) {
|
|
|
|
IOStatus io_s;
|
2017-06-24 23:06:43 +02:00
|
|
|
|
2017-11-15 17:22:54 +01:00
|
|
|
assert(!write_group.leader->disable_wal);
|
|
|
|
// Same holds for all in the batch group
|
2017-06-24 23:06:43 +02:00
|
|
|
WriteBatch tmp_batch;
|
|
|
|
size_t write_with_wal = 0;
|
2017-11-02 01:23:52 +01:00
|
|
|
WriteBatch* to_be_cached_state = nullptr;
|
2017-06-24 23:06:43 +02:00
|
|
|
WriteBatch* merged_batch =
|
2017-11-02 01:23:52 +01:00
|
|
|
MergeBatch(write_group, &tmp_batch, &write_with_wal, &to_be_cached_state);
|
2017-06-24 23:06:43 +02:00
|
|
|
|
|
|
|
// We need to lock log_write_mutex_ since logs_ and alive_log_files might be
|
|
|
|
// pushed back concurrently
|
|
|
|
log_write_mutex_.Lock();
|
2017-06-28 22:05:52 +02:00
|
|
|
if (merged_batch == write_group.leader->batch) {
|
|
|
|
write_group.leader->log_used = logfile_number_;
|
|
|
|
} else if (write_with_wal > 1) {
|
|
|
|
for (auto writer : write_group) {
|
|
|
|
writer->log_used = logfile_number_;
|
|
|
|
}
|
|
|
|
}
|
2017-11-11 02:18:01 +01:00
|
|
|
*last_sequence = versions_->FetchAddLastAllocatedSequence(seq_inc);
|
2017-06-24 23:06:43 +02:00
|
|
|
auto sequence = *last_sequence + 1;
|
|
|
|
WriteBatchInternal::SetSequence(merged_batch, sequence);
|
|
|
|
|
|
|
|
log::Writer* log_writer = logs_.back().writer;
|
|
|
|
uint64_t log_size;
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
io_s = WriteToWAL(*merged_batch, log_writer, log_used, &log_size);
|
2017-11-02 01:23:52 +01:00
|
|
|
if (to_be_cached_state) {
|
|
|
|
cached_recoverable_state_ = *to_be_cached_state;
|
2019-03-28 00:13:08 +01:00
|
|
|
cached_recoverable_state_empty_ = false;
|
2017-11-02 01:23:52 +01:00
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
log_write_mutex_.Unlock();
|
|
|
|
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
if (io_s.ok()) {
|
2017-06-30 01:57:13 +02:00
|
|
|
const bool concurrent = true;
|
2017-06-24 23:06:43 +02:00
|
|
|
auto stats = default_cf_internal_stats_;
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWalFileBytes, log_size,
|
|
|
|
concurrent);
|
2017-06-24 23:06:43 +02:00
|
|
|
RecordTick(stats_, WAL_FILE_BYTES, log_size);
|
2019-09-07 02:29:00 +02:00
|
|
|
stats->AddDBStats(InternalStats::kIntStatsWriteWithWal, write_with_wal,
|
2017-06-30 01:57:13 +02:00
|
|
|
concurrent);
|
2017-06-24 23:06:43 +02:00
|
|
|
RecordTick(stats_, WRITE_WITH_WAL, write_with_wal);
|
|
|
|
}
|
Pass IOStatus to write path and set retryable IO Error as hard error in BG jobs (#6487)
Summary:
In the current code base, we use Status to get and store the returned status from the call. Specifically, for IO related functions, the current Status cannot reflect the IO Error details such as error scope, error retryable attribute, and others. With the implementation of https://github.com/facebook/rocksdb/issues/5761, we have the new Wrapper for IO, which returns IOStatus instead of Status. However, the IOStatus is purged at the lower level of write path and transferred to Status.
The first job of this PR is to pass the IOStatus to the write path (flush, WAL write, and Compaction). The second job is to identify the Retryable IO Error as HardError, and set the bg_error_ as HardError. In this case, the DB Instance becomes read only. User is informed of the Status and need to take actions to deal with it (e.g., call db->Resume()).
Pull Request resolved: https://github.com/facebook/rocksdb/pull/6487
Test Plan: Added the testing case to error_handler_fs_test. Pass make asan_check
Reviewed By: anand1976
Differential Revision: D20685017
Pulled By: zhichao-cao
fbshipit-source-id: ff85f042896243abcd6ef37877834e26f36b6eb0
2020-03-28 00:03:05 +01:00
|
|
|
return io_s;
|
2017-06-24 23:06:43 +02:00
|
|
|
}
|
|
|
|
|
2017-11-02 01:23:52 +01:00
|
|
|
Status DBImpl::WriteRecoverableState() {
|
|
|
|
mutex_.AssertHeld();
|
|
|
|
if (!cached_recoverable_state_empty_) {
|
|
|
|
bool dont_care_bool;
|
|
|
|
SequenceNumber next_seq;
|
2017-11-11 02:18:01 +01:00
|
|
|
if (two_write_queues_) {
|
2017-11-02 01:23:52 +01:00
|
|
|
log_write_mutex_.Lock();
|
|
|
|
}
|
2018-03-29 23:30:37 +02:00
|
|
|
SequenceNumber seq;
|
|
|
|
if (two_write_queues_) {
|
|
|
|
seq = versions_->FetchAddLastAllocatedSequence(0);
|
|
|
|
} else {
|
|
|
|
seq = versions_->LastSequence();
|
|
|
|
}
|
2017-12-01 08:39:56 +01:00
|
|
|
WriteBatchInternal::SetSequence(&cached_recoverable_state_, seq + 1);
|
2017-11-02 01:23:52 +01:00
|
|
|
auto status = WriteBatchInternal::InsertInto(
|
|
|
|
&cached_recoverable_state_, column_family_memtables_.get(),
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
&flush_scheduler_, &trim_history_scheduler_, true,
|
|
|
|
0 /*recovery_log_number*/, this, false /* concurrent_memtable_writes */,
|
|
|
|
&next_seq, &dont_care_bool, seq_per_batch_);
|
2017-12-01 08:39:56 +01:00
|
|
|
auto last_seq = next_seq - 1;
|
|
|
|
if (two_write_queues_) {
|
|
|
|
versions_->FetchAddLastAllocatedSequence(last_seq - seq);
|
2018-03-29 23:30:37 +02:00
|
|
|
versions_->SetLastPublishedSequence(last_seq);
|
2017-12-01 08:39:56 +01:00
|
|
|
}
|
|
|
|
versions_->SetLastSequence(last_seq);
|
2017-11-11 02:18:01 +01:00
|
|
|
if (two_write_queues_) {
|
2017-11-02 01:23:52 +01:00
|
|
|
log_write_mutex_.Unlock();
|
|
|
|
}
|
2018-03-28 21:01:09 +02:00
|
|
|
if (status.ok() && recoverable_state_pre_release_callback_) {
|
|
|
|
const bool DISABLE_MEMTABLE = true;
|
|
|
|
for (uint64_t sub_batch_seq = seq + 1;
|
|
|
|
sub_batch_seq < next_seq && status.ok(); sub_batch_seq++) {
|
2019-04-03 00:14:41 +02:00
|
|
|
uint64_t const no_log_num = 0;
|
2019-05-15 22:48:59 +02:00
|
|
|
// Unlock it since the callback might end up locking mutex. e.g.,
|
|
|
|
// AddCommitted -> AdvanceMaxEvictedSeq -> GetSnapshotListFromDB
|
|
|
|
mutex_.Unlock();
|
2018-03-28 21:01:09 +02:00
|
|
|
status = recoverable_state_pre_release_callback_->Callback(
|
2019-06-10 20:47:16 +02:00
|
|
|
sub_batch_seq, !DISABLE_MEMTABLE, no_log_num, 0, 1);
|
2019-05-15 22:48:59 +02:00
|
|
|
mutex_.Lock();
|
2018-03-28 21:01:09 +02:00
|
|
|
}
|
|
|
|
}
|
2017-11-02 01:23:52 +01:00
|
|
|
if (status.ok()) {
|
|
|
|
cached_recoverable_state_.Clear();
|
|
|
|
cached_recoverable_state_empty_ = true;
|
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
2018-10-27 00:06:44 +02:00
|
|
|
void DBImpl::SelectColumnFamiliesForAtomicFlush(
|
|
|
|
autovector<ColumnFamilyData*>* cfds) {
|
|
|
|
for (ColumnFamilyData* cfd : *versions_->GetColumnFamilySet()) {
|
|
|
|
if (cfd->IsDropped()) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (cfd->imm()->NumNotFlushed() != 0 || !cfd->mem()->IsEmpty() ||
|
|
|
|
!cached_recoverable_state_empty_.load()) {
|
|
|
|
cfds->push_back(cfd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Assign sequence number for atomic flush.
|
|
|
|
void DBImpl::AssignAtomicFlushSeq(const autovector<ColumnFamilyData*>& cfds) {
|
2018-11-12 21:22:10 +01:00
|
|
|
assert(immutable_db_options_.atomic_flush);
|
2018-10-27 00:06:44 +02:00
|
|
|
auto seq = versions_->LastSequence();
|
|
|
|
for (auto cfd : cfds) {
|
|
|
|
cfd->imm()->AssignAtomicFlushSeq(seq);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-09-28 02:37:08 +02:00
|
|
|
Status DBImpl::SwitchWAL(WriteContext* write_context) {
|
2017-04-06 02:14:05 +02:00
|
|
|
mutex_.AssertHeld();
|
|
|
|
assert(write_context != nullptr);
|
|
|
|
Status status;
|
|
|
|
|
|
|
|
if (alive_log_files_.begin()->getting_flushed) {
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
auto oldest_alive_log = alive_log_files_.begin()->number;
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
2018-05-04 00:35:11 +02:00
|
|
|
bool flush_wont_release_oldest_log = false;
|
|
|
|
if (allow_2pc()) {
|
2019-01-02 20:15:01 +01:00
|
|
|
auto oldest_log_with_uncommitted_prep =
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
2018-05-04 00:35:11 +02:00
|
|
|
logs_with_prep_tracker_.FindMinLogContainingOutstandingPrep();
|
|
|
|
|
2019-01-02 20:15:01 +01:00
|
|
|
assert(oldest_log_with_uncommitted_prep == 0 ||
|
|
|
|
oldest_log_with_uncommitted_prep >= oldest_alive_log);
|
|
|
|
if (oldest_log_with_uncommitted_prep > 0 &&
|
|
|
|
oldest_log_with_uncommitted_prep == oldest_alive_log) {
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
2018-05-04 00:35:11 +02:00
|
|
|
if (unable_to_release_oldest_log_) {
|
2017-04-06 02:14:05 +02:00
|
|
|
// we already attempted to flush all column families dependent on
|
2019-01-02 20:15:01 +01:00
|
|
|
// the oldest alive log but the log still contained uncommitted
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
2018-05-04 00:35:11 +02:00
|
|
|
// transactions so there is still nothing that we can do.
|
2017-04-06 02:14:05 +02:00
|
|
|
return status;
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
2018-05-04 00:35:11 +02:00
|
|
|
} else {
|
|
|
|
ROCKS_LOG_WARN(
|
|
|
|
immutable_db_options_.info_log,
|
2019-01-02 20:15:01 +01:00
|
|
|
"Unable to release oldest log due to uncommitted transaction");
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
2018-05-04 00:35:11 +02:00
|
|
|
unable_to_release_oldest_log_ = true;
|
|
|
|
flush_wont_release_oldest_log = true;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
2018-05-04 00:35:11 +02:00
|
|
|
}
|
|
|
|
if (!flush_wont_release_oldest_log) {
|
2017-04-06 02:14:05 +02:00
|
|
|
// we only mark this log as getting flushed if we have successfully
|
|
|
|
// flushed all data in this log. If this log contains outstanding prepared
|
2019-03-28 00:13:08 +01:00
|
|
|
// transactions then we cannot flush this log until those transactions are
|
|
|
|
// commited.
|
Skip deleted WALs during recovery
Summary:
This patch record min log number to keep to the manifest while flushing SST files to ignore them and any WAL older than them during recovery. This is to avoid scenarios when we have a gap between the WAL files are fed to the recovery procedure. The gap could happen by for example out-of-order WAL deletion. Such gap could cause problems in 2PC recovery where the prepared and commit entry are placed into two separate WAL and gap in the WALs could result into not processing the WAL with the commit entry and hence breaking the 2PC recovery logic.
Before the commit, for 2PC case, we determined which log number to keep in FindObsoleteFiles(). We looked at the earliest logs with outstanding prepare entries, or prepare entries whose respective commit or abort are in memtable. With the commit, the same calculation is done while we apply the SST flush. Just before installing the flush file, we precompute the earliest log file to keep after the flush finishes using the same logic (but skipping the memtables just flushed), record this information to the manifest entry for this new flushed SST file. This pre-computed value is also remembered in memory, and will later be used to determine whether a log file can be deleted. This value is unlikely to change until next flush because the commit entry will stay in memtable. (In WritePrepared, we could have removed the older log files as soon as all prepared entries are committed. It's not yet done anyway. Even if we do it, the only thing we loss with this new approach is earlier log deletion between two flushes, which does not guarantee to happen anyway because the obsolete file clean-up function is only executed after flush or compaction)
This min log number to keep is stored in the manifest using the safely-ignore customized field of AddFile entry, in order to guarantee that the DB generated using newer release can be opened by previous releases no older than 4.2.
Closes https://github.com/facebook/rocksdb/pull/3765
Differential Revision: D7747618
Pulled By: siying
fbshipit-source-id: d00c92105b4f83852e9754a1b70d6b64cb590729
2018-05-04 00:35:11 +02:00
|
|
|
unable_to_release_oldest_log_ = false;
|
2017-04-06 02:14:05 +02:00
|
|
|
alive_log_files_.begin()->getting_flushed = true;
|
|
|
|
}
|
|
|
|
|
2019-03-28 00:13:08 +01:00
|
|
|
ROCKS_LOG_INFO(
|
|
|
|
immutable_db_options_.info_log,
|
|
|
|
"Flushing all column families with data in WAL number %" PRIu64
|
|
|
|
". Total log size is %" PRIu64 " while max_total_wal_size is %" PRIu64,
|
|
|
|
oldest_alive_log, total_log_size_.load(), GetMaxTotalWalSize());
|
2017-04-06 02:14:05 +02:00
|
|
|
// no need to refcount because drop is happening in write thread, so can't
|
|
|
|
// happen while we're in the write thread
|
2018-10-27 00:06:44 +02:00
|
|
|
autovector<ColumnFamilyData*> cfds;
|
2018-11-12 21:22:10 +01:00
|
|
|
if (immutable_db_options_.atomic_flush) {
|
2018-10-27 00:06:44 +02:00
|
|
|
SelectColumnFamiliesForAtomicFlush(&cfds);
|
|
|
|
} else {
|
|
|
|
for (auto cfd : *versions_->GetColumnFamilySet()) {
|
|
|
|
if (cfd->IsDropped()) {
|
|
|
|
continue;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
2018-10-27 00:06:44 +02:00
|
|
|
if (cfd->OldestLogToKeep() <= oldest_alive_log) {
|
|
|
|
cfds.push_back(cfd);
|
|
|
|
}
|
|
|
|
}
|
2019-07-01 20:53:25 +02:00
|
|
|
MaybeFlushStatsCF(&cfds);
|
2018-10-27 00:06:44 +02:00
|
|
|
}
|
2019-11-15 22:59:03 +01:00
|
|
|
WriteThread::Writer nonmem_w;
|
|
|
|
if (two_write_queues_) {
|
|
|
|
nonmem_write_thread_.EnterUnbatched(&nonmem_w, &mutex_);
|
|
|
|
}
|
|
|
|
|
2018-10-27 00:06:44 +02:00
|
|
|
for (const auto cfd : cfds) {
|
|
|
|
cfd->Ref();
|
|
|
|
status = SwitchMemtable(cfd, write_context);
|
2019-12-13 04:02:51 +01:00
|
|
|
cfd->UnrefAndTryDelete();
|
2018-10-27 00:06:44 +02:00
|
|
|
if (!status.ok()) {
|
|
|
|
break;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
}
|
2019-11-15 22:59:03 +01:00
|
|
|
if (two_write_queues_) {
|
|
|
|
nonmem_write_thread_.ExitUnbatched(&nonmem_w);
|
|
|
|
}
|
|
|
|
|
2018-08-24 22:17:29 +02:00
|
|
|
if (status.ok()) {
|
2018-11-12 21:22:10 +01:00
|
|
|
if (immutable_db_options_.atomic_flush) {
|
2018-10-27 00:06:44 +02:00
|
|
|
AssignAtomicFlushSeq(cfds);
|
|
|
|
}
|
|
|
|
for (auto cfd : cfds) {
|
|
|
|
cfd->imm()->FlushRequested();
|
2020-12-02 18:29:50 +01:00
|
|
|
if (!immutable_db_options_.atomic_flush) {
|
|
|
|
FlushRequest flush_req;
|
|
|
|
GenerateFlushRequest({cfd}, &flush_req);
|
2021-04-08 08:17:41 +02:00
|
|
|
SchedulePendingFlush(flush_req, FlushReason::kWalFull);
|
2020-12-02 18:29:50 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (immutable_db_options_.atomic_flush) {
|
|
|
|
FlushRequest flush_req;
|
|
|
|
GenerateFlushRequest(cfds, &flush_req);
|
2021-04-08 08:17:41 +02:00
|
|
|
SchedulePendingFlush(flush_req, FlushReason::kWalFull);
|
2018-10-27 00:06:44 +02:00
|
|
|
}
|
2018-08-24 22:17:29 +02:00
|
|
|
MaybeScheduleFlushOrCompaction();
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2021-04-08 08:17:41 +02:00
|
|
|
Status DBImpl::HandleWriteBufferManagerFlush(WriteContext* write_context) {
|
2017-04-06 02:14:05 +02:00
|
|
|
mutex_.AssertHeld();
|
|
|
|
assert(write_context != nullptr);
|
|
|
|
Status status;
|
|
|
|
|
|
|
|
// Before a new memtable is added in SwitchMemtable(),
|
|
|
|
// write_buffer_manager_->ShouldFlush() will keep returning true. If another
|
|
|
|
// thread is writing to another DB with the same write buffer, they may also
|
|
|
|
// be flushed. We may end up with flushing much more DBs than needed. It's
|
|
|
|
// suboptimal but still correct.
|
|
|
|
ROCKS_LOG_INFO(
|
|
|
|
immutable_db_options_.info_log,
|
2021-04-08 08:17:41 +02:00
|
|
|
"Flushing column family with oldest memtable entry. Write buffers are "
|
2019-04-04 21:05:42 +02:00
|
|
|
"using %" ROCKSDB_PRIszt " bytes out of a total of %" ROCKSDB_PRIszt ".",
|
2017-04-06 02:14:05 +02:00
|
|
|
write_buffer_manager_->memory_usage(),
|
|
|
|
write_buffer_manager_->buffer_size());
|
|
|
|
// no need to refcount because drop is happening in write thread, so can't
|
|
|
|
// happen while we're in the write thread
|
2018-10-27 00:06:44 +02:00
|
|
|
autovector<ColumnFamilyData*> cfds;
|
2018-11-12 21:22:10 +01:00
|
|
|
if (immutable_db_options_.atomic_flush) {
|
2018-10-27 00:06:44 +02:00
|
|
|
SelectColumnFamiliesForAtomicFlush(&cfds);
|
|
|
|
} else {
|
|
|
|
ColumnFamilyData* cfd_picked = nullptr;
|
|
|
|
SequenceNumber seq_num_for_cf_picked = kMaxSequenceNumber;
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2018-10-27 00:06:44 +02:00
|
|
|
for (auto cfd : *versions_->GetColumnFamilySet()) {
|
|
|
|
if (cfd->IsDropped()) {
|
|
|
|
continue;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
2018-10-27 00:06:44 +02:00
|
|
|
if (!cfd->mem()->IsEmpty()) {
|
|
|
|
// We only consider active mem table, hoping immutable memtable is
|
|
|
|
// already in the process of flushing.
|
|
|
|
uint64_t seq = cfd->mem()->GetCreationSeq();
|
|
|
|
if (cfd_picked == nullptr || seq < seq_num_for_cf_picked) {
|
|
|
|
cfd_picked = cfd;
|
|
|
|
seq_num_for_cf_picked = seq;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (cfd_picked != nullptr) {
|
|
|
|
cfds.push_back(cfd_picked);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
2019-07-01 20:53:25 +02:00
|
|
|
MaybeFlushStatsCF(&cfds);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
2018-08-24 22:17:29 +02:00
|
|
|
|
2019-11-15 22:59:03 +01:00
|
|
|
WriteThread::Writer nonmem_w;
|
|
|
|
if (two_write_queues_) {
|
|
|
|
nonmem_write_thread_.EnterUnbatched(&nonmem_w, &mutex_);
|
|
|
|
}
|
2018-08-24 22:17:29 +02:00
|
|
|
for (const auto cfd : cfds) {
|
2018-10-29 17:43:35 +01:00
|
|
|
if (cfd->mem()->IsEmpty()) {
|
|
|
|
continue;
|
|
|
|
}
|
2018-08-24 22:17:29 +02:00
|
|
|
cfd->Ref();
|
|
|
|
status = SwitchMemtable(cfd, write_context);
|
2019-12-13 04:02:51 +01:00
|
|
|
cfd->UnrefAndTryDelete();
|
2018-08-24 22:17:29 +02:00
|
|
|
if (!status.ok()) {
|
|
|
|
break;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
2018-08-24 22:17:29 +02:00
|
|
|
}
|
2019-11-15 22:59:03 +01:00
|
|
|
if (two_write_queues_) {
|
|
|
|
nonmem_write_thread_.ExitUnbatched(&nonmem_w);
|
|
|
|
}
|
|
|
|
|
2018-08-24 22:17:29 +02:00
|
|
|
if (status.ok()) {
|
2018-11-12 21:22:10 +01:00
|
|
|
if (immutable_db_options_.atomic_flush) {
|
2018-10-27 00:06:44 +02:00
|
|
|
AssignAtomicFlushSeq(cfds);
|
|
|
|
}
|
|
|
|
for (const auto cfd : cfds) {
|
|
|
|
cfd->imm()->FlushRequested();
|
2020-12-02 18:29:50 +01:00
|
|
|
if (!immutable_db_options_.atomic_flush) {
|
|
|
|
FlushRequest flush_req;
|
|
|
|
GenerateFlushRequest({cfd}, &flush_req);
|
2021-04-08 08:17:41 +02:00
|
|
|
SchedulePendingFlush(flush_req, FlushReason::kWriteBufferManager);
|
2020-12-02 18:29:50 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (immutable_db_options_.atomic_flush) {
|
|
|
|
FlushRequest flush_req;
|
|
|
|
GenerateFlushRequest(cfds, &flush_req);
|
2021-04-08 08:17:41 +02:00
|
|
|
SchedulePendingFlush(flush_req, FlushReason::kWriteBufferManager);
|
2018-10-27 00:06:44 +02:00
|
|
|
}
|
2018-08-24 22:17:29 +02:00
|
|
|
MaybeScheduleFlushOrCompaction();
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
uint64_t DBImpl::GetMaxTotalWalSize() const {
|
|
|
|
mutex_.AssertHeld();
|
|
|
|
return mutable_db_options_.max_total_wal_size == 0
|
|
|
|
? 4 * max_total_in_memory_state_
|
|
|
|
: mutable_db_options_.max_total_wal_size;
|
|
|
|
}
|
|
|
|
|
|
|
|
// REQUIRES: mutex_ is held
|
|
|
|
// REQUIRES: this thread is currently at the front of the writer queue
|
|
|
|
Status DBImpl::DelayWrite(uint64_t num_bytes,
|
|
|
|
const WriteOptions& write_options) {
|
|
|
|
uint64_t time_delayed = 0;
|
|
|
|
bool delayed = false;
|
|
|
|
{
|
2021-03-15 12:32:24 +01:00
|
|
|
StopWatch sw(immutable_db_options_.clock, stats_, WRITE_STALL,
|
|
|
|
&time_delayed);
|
|
|
|
uint64_t delay =
|
|
|
|
write_controller_.GetDelay(immutable_db_options_.clock, num_bytes);
|
2017-04-06 02:14:05 +02:00
|
|
|
if (delay > 0) {
|
|
|
|
if (write_options.no_slowdown) {
|
2018-10-10 07:50:59 +02:00
|
|
|
return Status::Incomplete("Write stall");
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
TEST_SYNC_POINT("DBImpl::DelayWrite:Sleep");
|
|
|
|
|
2018-10-10 07:50:59 +02:00
|
|
|
// Notify write_thread_ about the stall so it can setup a barrier and
|
|
|
|
// fail any pending writers with no_slowdown
|
|
|
|
write_thread_.BeginWriteStall();
|
|
|
|
TEST_SYNC_POINT("DBImpl::DelayWrite:BeginWriteStallDone");
|
2017-04-06 02:14:05 +02:00
|
|
|
mutex_.Unlock();
|
2021-03-18 17:45:59 +01:00
|
|
|
// We will delay the write until we have slept for `delay` microseconds
|
|
|
|
// or we don't need a delay anymore. We check for cancellation every 1ms
|
|
|
|
// (slightly longer because WriteController minimum delay is 1ms, in
|
|
|
|
// case of sleep imprecision, rounding, etc.)
|
|
|
|
const uint64_t kDelayInterval = 1001;
|
2017-04-06 02:14:05 +02:00
|
|
|
uint64_t stall_end = sw.start_time() + delay;
|
|
|
|
while (write_controller_.NeedsDelay()) {
|
2021-03-15 12:32:24 +01:00
|
|
|
if (immutable_db_options_.clock->NowMicros() >= stall_end) {
|
2017-04-06 02:14:05 +02:00
|
|
|
// We already delayed this write `delay` microseconds
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
delayed = true;
|
|
|
|
// Sleep for 0.001 seconds
|
2021-03-15 12:32:24 +01:00
|
|
|
immutable_db_options_.clock->SleepForMicroseconds(kDelayInterval);
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
mutex_.Lock();
|
2018-10-10 07:50:59 +02:00
|
|
|
write_thread_.EndWriteStall();
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
Auto recovery from out of space errors (#4164)
Summary:
This commit implements automatic recovery from a Status::NoSpace() error
during background operations such as write callback, flush and
compaction. The broad design is as follows -
1. Compaction errors are treated as soft errors and don't put the
database in read-only mode. A compaction is delayed until enough free
disk space is available to accomodate the compaction outputs, which is
estimated based on the input size. This means that users can continue to
write, and we rely on the WriteController to delay or stop writes if the
compaction debt becomes too high due to persistent low disk space
condition
2. Errors during write callback and flush are treated as hard errors,
i.e the database is put in read-only mode and goes back to read-write
only fater certain recovery actions are taken.
3. Both types of recovery rely on the SstFileManagerImpl to poll for
sufficient disk space. We assume that there is a 1-1 mapping between an
SFM and the underlying OS storage container. For cases where multiple
DBs are hosted on a single storage container, the user is expected to
allocate a single SFM instance and use the same one for all the DBs. If
no SFM is specified by the user, DBImpl::Open() will allocate one, but
this will be one per DB and each DB will recover independently. The
recovery implemented by SFM is as follows -
a) On the first occurance of an out of space error during compaction,
subsequent
compactions will be delayed until the disk free space check indicates
enough available space. The required space is computed as the sum of
input sizes.
b) The free space check requirement will be removed once the amount of
free space is greater than the size reserved by in progress
compactions when the first error occured
c) If the out of space error is a hard error, a background thread in
SFM will poll for sufficient headroom before triggering the recovery
of the database and putting it in write-only mode. The headroom is
calculated as the sum of the write_buffer_size of all the DB instances
associated with the SFM
4. EventListener callbacks will be called at the start and completion of
automatic recovery. Users can disable the auto recov ery in the start
callback, and later initiate it manually by calling DB::Resume()
Todo:
1. More extensive testing
2. Add disk full condition to db_stress (follow-on PR)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4164
Differential Revision: D9846378
Pulled By: anand1976
fbshipit-source-id: 80ea875dbd7f00205e19c82215ff6e37da10da4a
2018-09-15 22:36:19 +02:00
|
|
|
// Don't wait if there's a background error, even if its a soft error. We
|
|
|
|
// might wait here indefinitely as the background compaction may never
|
|
|
|
// finish successfully, resulting in the stall condition lasting
|
|
|
|
// indefinitely
|
|
|
|
while (error_handler_.GetBGError().ok() && write_controller_.IsStopped()) {
|
2017-04-06 02:14:05 +02:00
|
|
|
if (write_options.no_slowdown) {
|
2018-10-10 07:50:59 +02:00
|
|
|
return Status::Incomplete("Write stall");
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
delayed = true;
|
2018-10-10 07:50:59 +02:00
|
|
|
|
|
|
|
// Notify write_thread_ about the stall so it can setup a barrier and
|
|
|
|
// fail any pending writers with no_slowdown
|
|
|
|
write_thread_.BeginWriteStall();
|
2017-04-06 02:14:05 +02:00
|
|
|
TEST_SYNC_POINT("DBImpl::DelayWrite:Wait");
|
|
|
|
bg_cv_.Wait();
|
2018-10-10 07:50:59 +02:00
|
|
|
write_thread_.EndWriteStall();
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
assert(!delayed || !write_options.no_slowdown);
|
|
|
|
if (delayed) {
|
2019-09-07 02:29:00 +02:00
|
|
|
default_cf_internal_stats_->AddDBStats(
|
|
|
|
InternalStats::kIntStatsWriteStallMicros, time_delayed);
|
2017-04-06 02:14:05 +02:00
|
|
|
RecordTick(stats_, STALL_MICROS, time_delayed);
|
|
|
|
}
|
|
|
|
|
Auto recovery from out of space errors (#4164)
Summary:
This commit implements automatic recovery from a Status::NoSpace() error
during background operations such as write callback, flush and
compaction. The broad design is as follows -
1. Compaction errors are treated as soft errors and don't put the
database in read-only mode. A compaction is delayed until enough free
disk space is available to accomodate the compaction outputs, which is
estimated based on the input size. This means that users can continue to
write, and we rely on the WriteController to delay or stop writes if the
compaction debt becomes too high due to persistent low disk space
condition
2. Errors during write callback and flush are treated as hard errors,
i.e the database is put in read-only mode and goes back to read-write
only fater certain recovery actions are taken.
3. Both types of recovery rely on the SstFileManagerImpl to poll for
sufficient disk space. We assume that there is a 1-1 mapping between an
SFM and the underlying OS storage container. For cases where multiple
DBs are hosted on a single storage container, the user is expected to
allocate a single SFM instance and use the same one for all the DBs. If
no SFM is specified by the user, DBImpl::Open() will allocate one, but
this will be one per DB and each DB will recover independently. The
recovery implemented by SFM is as follows -
a) On the first occurance of an out of space error during compaction,
subsequent
compactions will be delayed until the disk free space check indicates
enough available space. The required space is computed as the sum of
input sizes.
b) The free space check requirement will be removed once the amount of
free space is greater than the size reserved by in progress
compactions when the first error occured
c) If the out of space error is a hard error, a background thread in
SFM will poll for sufficient headroom before triggering the recovery
of the database and putting it in write-only mode. The headroom is
calculated as the sum of the write_buffer_size of all the DB instances
associated with the SFM
4. EventListener callbacks will be called at the start and completion of
automatic recovery. Users can disable the auto recov ery in the start
callback, and later initiate it manually by calling DB::Resume()
Todo:
1. More extensive testing
2. Add disk full condition to db_stress (follow-on PR)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/4164
Differential Revision: D9846378
Pulled By: anand1976
fbshipit-source-id: 80ea875dbd7f00205e19c82215ff6e37da10da4a
2018-09-15 22:36:19 +02:00
|
|
|
// If DB is not in read-only mode and write_controller is not stopping
|
|
|
|
// writes, we can ignore any background errors and allow the write to
|
|
|
|
// proceed
|
|
|
|
Status s;
|
|
|
|
if (write_controller_.IsStopped()) {
|
|
|
|
// If writes are still stopped, it means we bailed due to a background
|
|
|
|
// error
|
|
|
|
s = Status::Incomplete(error_handler_.GetBGError().ToString());
|
|
|
|
}
|
|
|
|
if (error_handler_.IsDBStopped()) {
|
|
|
|
s = error_handler_.GetBGError();
|
|
|
|
}
|
|
|
|
return s;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
2021-04-21 22:53:05 +02:00
|
|
|
// REQUIRES: mutex_ is held
|
|
|
|
// REQUIRES: this thread is currently at the front of the writer queue
|
|
|
|
void DBImpl::WriteBufferManagerStallWrites() {
|
|
|
|
mutex_.AssertHeld();
|
|
|
|
// First block future writer threads who want to add themselves to the queue
|
|
|
|
// of WriteThread.
|
|
|
|
write_thread_.BeginWriteStall();
|
|
|
|
mutex_.Unlock();
|
|
|
|
|
|
|
|
// Change the state to State::Blocked.
|
|
|
|
static_cast<WBMStallInterface*>(wbm_stall_.get())
|
|
|
|
->SetState(WBMStallInterface::State::BLOCKED);
|
|
|
|
// Then WriteBufferManager will add DB instance to its queue
|
|
|
|
// and block this thread by calling WBMStallInterface::Block().
|
|
|
|
write_buffer_manager_->BeginWriteStall(wbm_stall_.get());
|
|
|
|
wbm_stall_->Block();
|
|
|
|
|
|
|
|
mutex_.Lock();
|
|
|
|
// Stall has ended. Signal writer threads so that they can add
|
|
|
|
// themselves to the WriteThread queue for writes.
|
|
|
|
write_thread_.EndWriteStall();
|
|
|
|
}
|
|
|
|
|
2017-06-05 23:42:34 +02:00
|
|
|
Status DBImpl::ThrottleLowPriWritesIfNeeded(const WriteOptions& write_options,
|
|
|
|
WriteBatch* my_batch) {
|
|
|
|
assert(write_options.low_pri);
|
|
|
|
// This is called outside the DB mutex. Although it is safe to make the call,
|
|
|
|
// the consistency condition is not guaranteed to hold. It's OK to live with
|
|
|
|
// it in this case.
|
|
|
|
// If we need to speed compaction, it means the compaction is left behind
|
|
|
|
// and we start to limit low pri writes to a limit.
|
|
|
|
if (write_controller_.NeedSpeedupCompaction()) {
|
|
|
|
if (allow_2pc() && (my_batch->HasCommit() || my_batch->HasRollback())) {
|
|
|
|
// For 2PC, we only rate limit prepare, not commit.
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
if (write_options.no_slowdown) {
|
2020-02-10 21:31:12 +01:00
|
|
|
return Status::Incomplete("Low priority write stall");
|
2017-06-05 23:42:34 +02:00
|
|
|
} else {
|
|
|
|
assert(my_batch != nullptr);
|
|
|
|
// Rate limit those writes. The reason that we don't completely wait
|
|
|
|
// is that in case the write is heavy, low pri writes may never have
|
|
|
|
// a chance to run. Now we guarantee we are still slowly making
|
|
|
|
// progress.
|
2018-04-24 02:53:27 +02:00
|
|
|
PERF_TIMER_GUARD(write_delay_time);
|
2017-06-13 23:51:22 +02:00
|
|
|
write_controller_.low_pri_rate_limiter()->Request(
|
|
|
|
my_batch->GetDataSize(), Env::IO_HIGH, nullptr /* stats */,
|
|
|
|
RateLimiter::OpType::kWrite);
|
2017-06-05 23:42:34 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
2019-07-01 20:53:25 +02:00
|
|
|
void DBImpl::MaybeFlushStatsCF(autovector<ColumnFamilyData*>* cfds) {
|
|
|
|
assert(cfds != nullptr);
|
|
|
|
if (!cfds->empty() && immutable_db_options_.persist_stats_to_disk) {
|
|
|
|
ColumnFamilyData* cfd_stats =
|
|
|
|
versions_->GetColumnFamilySet()->GetColumnFamily(
|
|
|
|
kPersistentStatsColumnFamilyName);
|
|
|
|
if (cfd_stats != nullptr && !cfd_stats->mem()->IsEmpty()) {
|
|
|
|
for (ColumnFamilyData* cfd : *cfds) {
|
|
|
|
if (cfd == cfd_stats) {
|
|
|
|
// stats CF already included in cfds
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
// force flush stats CF when its log number is less than all other CF's
|
|
|
|
// log numbers
|
|
|
|
bool force_flush_stats_cf = true;
|
|
|
|
for (auto* loop_cfd : *versions_->GetColumnFamilySet()) {
|
|
|
|
if (loop_cfd == cfd_stats) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (loop_cfd->GetLogNumber() <= cfd_stats->GetLogNumber()) {
|
|
|
|
force_flush_stats_cf = false;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (force_flush_stats_cf) {
|
|
|
|
cfds->push_back(cfd_stats);
|
|
|
|
ROCKS_LOG_INFO(immutable_db_options_.info_log,
|
|
|
|
"Force flushing stats CF with automated flush "
|
|
|
|
"to avoid holding old logs");
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
Status DBImpl::TrimMemtableHistory(WriteContext* context) {
|
|
|
|
autovector<ColumnFamilyData*> cfds;
|
|
|
|
ColumnFamilyData* tmp_cfd;
|
|
|
|
while ((tmp_cfd = trim_history_scheduler_.TakeNextColumnFamily()) !=
|
|
|
|
nullptr) {
|
|
|
|
cfds.push_back(tmp_cfd);
|
|
|
|
}
|
|
|
|
for (auto& cfd : cfds) {
|
|
|
|
autovector<MemTable*> to_delete;
|
2020-08-21 22:27:29 +02:00
|
|
|
bool trimmed = cfd->imm()->TrimHistory(
|
2021-12-02 20:44:29 +01:00
|
|
|
&context->memtables_to_free_, cfd->mem()->MemoryAllocatedBytes());
|
2020-08-21 22:27:29 +02:00
|
|
|
if (trimmed) {
|
2019-12-13 21:45:49 +01:00
|
|
|
context->superversion_context.NewSuperVersion();
|
|
|
|
assert(context->superversion_context.new_superversion.get() != nullptr);
|
|
|
|
cfd->InstallSuperVersion(&context->superversion_context, &mutex_);
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
}
|
|
|
|
|
2019-12-13 04:02:51 +01:00
|
|
|
if (cfd->UnrefAndTryDelete()) {
|
Refactor trimming logic for immutable memtables (#5022)
Summary:
MyRocks currently sets `max_write_buffer_number_to_maintain` in order to maintain enough history for transaction conflict checking. The effectiveness of this approach depends on the size of memtables. When memtables are small, it may not keep enough history; when memtables are large, this may consume too much memory.
We are proposing a new way to configure memtable list history: by limiting the memory usage of immutable memtables. The new option is `max_write_buffer_size_to_maintain` and it will take precedence over the old `max_write_buffer_number_to_maintain` if they are both set to non-zero values. The new option accounts for the total memory usage of flushed immutable memtables and mutable memtable. When the total usage exceeds the limit, RocksDB may start dropping immutable memtables (which is also called trimming history), starting from the oldest one.
The semantics of the old option actually works both as an upper bound and lower bound. History trimming will start if number of immutable memtables exceeds the limit, but it will never go below (limit-1) due to history trimming.
In order the mimic the behavior with the new option, history trimming will stop if dropping the next immutable memtable causes the total memory usage go below the size limit. For example, assuming the size limit is set to 64MB, and there are 3 immutable memtables with sizes of 20, 30, 30. Although the total memory usage is 80MB > 64MB, dropping the oldest memtable will reduce the memory usage to 60MB < 64MB, so in this case no memtable will be dropped.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/5022
Differential Revision: D14394062
Pulled By: miasantreble
fbshipit-source-id: 60457a509c6af89d0993f988c9b5c2aa9e45f5c5
2019-08-23 22:54:09 +02:00
|
|
|
cfd = nullptr;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return Status::OK();
|
|
|
|
}
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
Status DBImpl::ScheduleFlushes(WriteContext* context) {
|
2018-10-27 00:06:44 +02:00
|
|
|
autovector<ColumnFamilyData*> cfds;
|
2018-11-12 21:22:10 +01:00
|
|
|
if (immutable_db_options_.atomic_flush) {
|
2018-10-27 00:06:44 +02:00
|
|
|
SelectColumnFamiliesForAtomicFlush(&cfds);
|
|
|
|
for (auto cfd : cfds) {
|
|
|
|
cfd->Ref();
|
|
|
|
}
|
|
|
|
flush_scheduler_.Clear();
|
|
|
|
} else {
|
|
|
|
ColumnFamilyData* tmp_cfd;
|
|
|
|
while ((tmp_cfd = flush_scheduler_.TakeNextColumnFamily()) != nullptr) {
|
|
|
|
cfds.push_back(tmp_cfd);
|
|
|
|
}
|
2019-07-01 20:53:25 +02:00
|
|
|
MaybeFlushStatsCF(&cfds);
|
2018-10-27 00:06:44 +02:00
|
|
|
}
|
2018-08-24 22:17:29 +02:00
|
|
|
Status status;
|
2019-11-15 22:59:03 +01:00
|
|
|
WriteThread::Writer nonmem_w;
|
|
|
|
if (two_write_queues_) {
|
|
|
|
nonmem_write_thread_.EnterUnbatched(&nonmem_w, &mutex_);
|
|
|
|
}
|
|
|
|
|
2018-10-27 00:06:44 +02:00
|
|
|
for (auto& cfd : cfds) {
|
2018-10-29 17:43:35 +01:00
|
|
|
if (!cfd->mem()->IsEmpty()) {
|
|
|
|
status = SwitchMemtable(cfd, context);
|
|
|
|
}
|
2019-12-13 04:02:51 +01:00
|
|
|
if (cfd->UnrefAndTryDelete()) {
|
2018-10-27 00:06:44 +02:00
|
|
|
cfd = nullptr;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
if (!status.ok()) {
|
2018-08-24 22:17:29 +02:00
|
|
|
break;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
2019-11-15 22:59:03 +01:00
|
|
|
|
|
|
|
if (two_write_queues_) {
|
|
|
|
nonmem_write_thread_.ExitUnbatched(&nonmem_w);
|
|
|
|
}
|
|
|
|
|
2018-08-24 22:17:29 +02:00
|
|
|
if (status.ok()) {
|
2018-11-12 21:22:10 +01:00
|
|
|
if (immutable_db_options_.atomic_flush) {
|
2018-10-27 00:06:44 +02:00
|
|
|
AssignAtomicFlushSeq(cfds);
|
2020-12-02 18:29:50 +01:00
|
|
|
FlushRequest flush_req;
|
|
|
|
GenerateFlushRequest(cfds, &flush_req);
|
|
|
|
SchedulePendingFlush(flush_req, FlushReason::kWriteBufferFull);
|
|
|
|
} else {
|
|
|
|
for (auto* cfd : cfds) {
|
|
|
|
FlushRequest flush_req;
|
|
|
|
GenerateFlushRequest({cfd}, &flush_req);
|
|
|
|
SchedulePendingFlush(flush_req, FlushReason::kWriteBufferFull);
|
|
|
|
}
|
2018-10-27 00:06:44 +02:00
|
|
|
}
|
2018-08-24 22:17:29 +02:00
|
|
|
MaybeScheduleFlushOrCompaction();
|
|
|
|
}
|
|
|
|
return status;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
#ifndef ROCKSDB_LITE
|
2018-03-05 22:08:17 +01:00
|
|
|
void DBImpl::NotifyOnMemTableSealed(ColumnFamilyData* /*cfd*/,
|
2017-04-06 02:14:05 +02:00
|
|
|
const MemTableInfo& mem_table_info) {
|
|
|
|
if (immutable_db_options_.listeners.size() == 0U) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
if (shutting_down_.load(std::memory_order_acquire)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (auto listener : immutable_db_options_.listeners) {
|
|
|
|
listener->OnMemTableSealed(mem_table_info);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif // ROCKSDB_LITE
|
|
|
|
|
|
|
|
// REQUIRES: mutex_ is held
|
|
|
|
// REQUIRES: this thread is currently at the front of the writer queue
|
2019-11-15 22:59:03 +01:00
|
|
|
// REQUIRES: this thread is currently at the front of the 2nd writer queue if
|
|
|
|
// two_write_queues_ is true (This is to simplify the reasoning.)
|
2018-08-24 22:17:29 +02:00
|
|
|
Status DBImpl::SwitchMemtable(ColumnFamilyData* cfd, WriteContext* context) {
|
2017-04-06 02:14:05 +02:00
|
|
|
mutex_.AssertHeld();
|
|
|
|
log::Writer* new_log = nullptr;
|
|
|
|
MemTable* new_mem = nullptr;
|
2020-07-15 20:02:44 +02:00
|
|
|
IOStatus io_s;
|
2017-04-06 02:14:05 +02:00
|
|
|
|
2017-11-02 01:23:52 +01:00
|
|
|
// Recoverable state is persisted in WAL. After memtable switch, WAL might
|
|
|
|
// be deleted, so we write the state to memtable to be persisted as well.
|
|
|
|
Status s = WriteRecoverableState();
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
2017-04-06 02:14:05 +02:00
|
|
|
// Attempt to switch to a new memtable and trigger flush of old.
|
|
|
|
// Do this without holding the dbmutex lock.
|
|
|
|
assert(versions_->prev_log_number() == 0);
|
2017-11-11 02:18:01 +01:00
|
|
|
if (two_write_queues_) {
|
2017-06-30 18:30:03 +02:00
|
|
|
log_write_mutex_.Lock();
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
bool creating_new_log = !log_empty_;
|
2017-11-11 02:18:01 +01:00
|
|
|
if (two_write_queues_) {
|
2017-06-30 18:30:03 +02:00
|
|
|
log_write_mutex_.Unlock();
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
uint64_t recycle_log_number = 0;
|
|
|
|
if (creating_new_log && immutable_db_options_.recycle_log_file_num &&
|
2018-01-09 21:51:10 +01:00
|
|
|
!log_recycle_files_.empty()) {
|
|
|
|
recycle_log_number = log_recycle_files_.front();
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
uint64_t new_log_number =
|
|
|
|
creating_new_log ? versions_->NewFileNumber() : logfile_number_;
|
|
|
|
const MutableCFOptions mutable_cf_options = *cfd->GetLatestMutableCFOptions();
|
|
|
|
|
2017-08-17 06:45:32 +02:00
|
|
|
// Set memtable_info for memtable sealed callback
|
2017-04-06 02:14:05 +02:00
|
|
|
#ifndef ROCKSDB_LITE
|
|
|
|
MemTableInfo memtable_info;
|
|
|
|
memtable_info.cf_name = cfd->GetName();
|
|
|
|
memtable_info.first_seqno = cfd->mem()->GetFirstSequenceNumber();
|
|
|
|
memtable_info.earliest_seqno = cfd->mem()->GetEarliestSequenceNumber();
|
|
|
|
memtable_info.num_entries = cfd->mem()->num_entries();
|
|
|
|
memtable_info.num_deletes = cfd->mem()->num_deletes();
|
|
|
|
#endif // ROCKSDB_LITE
|
|
|
|
// Log this later after lock release. It may be outdated, e.g., if background
|
|
|
|
// flush happens before logging, but that should be ok.
|
|
|
|
int num_imm_unflushed = cfd->imm()->NumNotFlushed();
|
|
|
|
const auto preallocate_block_size =
|
2019-03-28 00:13:08 +01:00
|
|
|
GetWalPreallocateBlockSize(mutable_cf_options.write_buffer_size);
|
2017-04-06 02:14:05 +02:00
|
|
|
mutex_.Unlock();
|
2019-04-16 03:47:24 +02:00
|
|
|
if (creating_new_log) {
|
|
|
|
// TODO: Write buffer size passed in should be max of all CF's instead
|
|
|
|
// of mutable_cf_options.write_buffer_size.
|
2020-07-15 20:02:44 +02:00
|
|
|
io_s = CreateWAL(new_log_number, recycle_log_number, preallocate_block_size,
|
|
|
|
&new_log);
|
|
|
|
if (s.ok()) {
|
|
|
|
s = io_s;
|
|
|
|
}
|
2019-04-16 03:47:24 +02:00
|
|
|
}
|
|
|
|
if (s.ok()) {
|
|
|
|
SequenceNumber seq = versions_->LastSequence();
|
2021-07-23 03:26:47 +02:00
|
|
|
new_mem = cfd->ConstructNewMemtable(mutable_cf_options, seq);
|
2019-04-16 03:47:24 +02:00
|
|
|
context->superversion_context.NewSuperVersion();
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
ROCKS_LOG_INFO(immutable_db_options_.info_log,
|
|
|
|
"[%s] New memtable created with log file: #%" PRIu64
|
|
|
|
". Immutable memtables: %d.\n",
|
|
|
|
cfd->GetName().c_str(), new_log_number, num_imm_unflushed);
|
|
|
|
mutex_.Lock();
|
2020-02-18 22:52:09 +01:00
|
|
|
if (recycle_log_number != 0) {
|
|
|
|
// Since renaming the file is done outside DB mutex, we need to ensure
|
|
|
|
// concurrent full purges don't delete the file while we're recycling it.
|
|
|
|
// To achieve that we hold the old log number in the recyclable list until
|
|
|
|
// after it has been renamed.
|
|
|
|
assert(log_recycle_files_.front() == recycle_log_number);
|
|
|
|
log_recycle_files_.pop_front();
|
|
|
|
}
|
2018-02-05 22:48:25 +01:00
|
|
|
if (s.ok() && creating_new_log) {
|
2017-06-28 22:05:52 +02:00
|
|
|
log_write_mutex_.Lock();
|
2017-04-06 02:14:05 +02:00
|
|
|
assert(new_log != nullptr);
|
2017-06-24 23:06:43 +02:00
|
|
|
if (!logs_.empty()) {
|
|
|
|
// Alway flush the buffer of the last log before switching to a new one
|
|
|
|
log::Writer* cur_log_writer = logs_.back().writer;
|
2020-07-15 20:02:44 +02:00
|
|
|
io_s = cur_log_writer->WriteBuffer();
|
|
|
|
if (s.ok()) {
|
|
|
|
s = io_s;
|
|
|
|
}
|
2018-02-05 22:48:25 +01:00
|
|
|
if (!s.ok()) {
|
|
|
|
ROCKS_LOG_WARN(immutable_db_options_.info_log,
|
|
|
|
"[%s] Failed to switch from #%" PRIu64 " to #%" PRIu64
|
2019-04-04 21:05:42 +02:00
|
|
|
" WAL file\n",
|
2018-02-05 22:48:25 +01:00
|
|
|
cfd->GetName().c_str(), cur_log_writer->get_log_number(),
|
|
|
|
new_log_number);
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
}
|
2019-03-15 23:15:01 +01:00
|
|
|
if (s.ok()) {
|
|
|
|
logfile_number_ = new_log_number;
|
|
|
|
log_empty_ = true;
|
|
|
|
log_dir_synced_ = false;
|
|
|
|
logs_.emplace_back(logfile_number_, new_log);
|
|
|
|
alive_log_files_.push_back(LogFileNumberSize(logfile_number_));
|
|
|
|
}
|
2017-06-24 23:06:43 +02:00
|
|
|
log_write_mutex_.Unlock();
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
2018-02-05 22:48:25 +01:00
|
|
|
|
|
|
|
if (!s.ok()) {
|
|
|
|
// how do we fail if we're not creating new log?
|
|
|
|
assert(creating_new_log);
|
2021-10-20 23:04:58 +02:00
|
|
|
delete new_mem;
|
|
|
|
delete new_log;
|
|
|
|
context->superversion_context.new_superversion.reset();
|
2019-03-15 23:15:01 +01:00
|
|
|
// We may have lost data from the WritableFileBuffer in-memory buffer for
|
|
|
|
// the current log, so treat it as a fatal error and set bg_error
|
2020-07-15 20:02:44 +02:00
|
|
|
if (!io_s.ok()) {
|
2020-12-08 05:09:55 +01:00
|
|
|
error_handler_.SetBGError(io_s, BackgroundErrorReason::kMemTable);
|
2020-07-15 20:02:44 +02:00
|
|
|
} else {
|
2020-12-08 05:09:55 +01:00
|
|
|
error_handler_.SetBGError(s, BackgroundErrorReason::kMemTable);
|
2020-07-15 20:02:44 +02:00
|
|
|
}
|
2019-03-15 23:15:01 +01:00
|
|
|
// Read back bg_error in order to get the right severity
|
|
|
|
s = error_handler_.GetBGError();
|
2018-02-05 22:48:25 +01:00
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
Track WAL obsoletion when updating empty CF's log number (#7781)
Summary:
In the write path, there is an optimization: when a new WAL is created during SwitchMemtable, we update the internal log number of the empty column families to the new WAL. `FindObsoleteFiles` marks a WAL as obsolete if the WAL's log number is less than `VersionSet::MinLogNumberWithUnflushedData`. After updating the empty column families' internal log number, `VersionSet::MinLogNumberWithUnflushedData` might change, so some WALs might become obsolete to be purged from disk.
For example, consider there are 3 column families: 0, 1, 2:
1. initially, all the column families' log number is 1;
2. write some data to cf0, and flush cf0, but the flush is pending;
3. now a new WAL 2 is created;
4. write data to cf1 and WAL 2, now cf0's log number is 1, cf1's log number is 2, cf2's log number is 2 (because cf1 and cf2 are empty, so their log numbers will be set to the highest log number);
5. now cf0's flush hasn't finished, flush cf1, a new WAL 3 is created, and cf1's flush finishes, now cf0's log number is 1, cf1's log number is 3, cf2's log number is 3, since WAL 1 still contains data for the unflushed cf0, no WAL can be deleted from disk;
6. now cf0's flush finishes, cf0's log number is 2 (because when cf0 was switching memtable, WAL 3 does not exist yet), cf1's log number is 3, cf2's log number is 3, so WAL 1 can be purged from disk now, but WAL 2 still cannot because `MinLogNumberToKeep()` is 2;
7. write data to cf2 and WAL 3, because cf0 is empty, its log number is updated to 3, so now cf0's log number is 3, cf1's log number is 3, cf2's log number is 3;
8. now if the background threads want to purge obsolete files from disk, WAL 2 can be purged because `MinLogNumberToKeep()` is 3. But there are only two flush results written to MANIFEST: the first is for flushing cf1, and the `MinLogNumberToKeep` is 1, the second is for flushing cf0, and the `MinLogNumberToKeep` is 2. So without this PR, if the DB crashes at this point and try to recover, `WalSet` will still expect WAL 2 to exist.
When WAL tracking is enabled, we assume WALs will only become obsolete after a flush result is written to MANIFEST in `MemtableList::TryInstallMemtableFlushResults` (or its atomic flush counterpart). The above situation breaks this assumption.
This PR tracks WAL obsoletion if necessary before updating the empty column families' log numbers.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7781
Test Plan:
watch existing tests and stress tests to pass.
`make -j48 blackbox_crash_test` on devserver
Reviewed By: ltamasi
Differential Revision: D25631695
Pulled By: cheng-chang
fbshipit-source-id: ca7fff967bdb42204b84226063d909893bc0a4ec
2020-12-19 06:33:20 +01:00
|
|
|
bool empty_cf_updated = false;
|
|
|
|
if (immutable_db_options_.track_and_verify_wals_in_manifest &&
|
|
|
|
!immutable_db_options_.allow_2pc && creating_new_log) {
|
|
|
|
// In non-2pc mode, WALs become obsolete if they do not contain unflushed
|
|
|
|
// data. Updating the empty CF's log number might cause some WALs to become
|
|
|
|
// obsolete. So we should track the WAL obsoletion event before actually
|
|
|
|
// updating the empty CF's log number.
|
|
|
|
uint64_t min_wal_number_to_keep =
|
|
|
|
versions_->PreComputeMinLogNumberWithUnflushedData(logfile_number_);
|
|
|
|
if (min_wal_number_to_keep >
|
|
|
|
versions_->GetWalSet().GetMinWalNumberToKeep()) {
|
|
|
|
// Get a snapshot of the empty column families.
|
|
|
|
// LogAndApply may release and reacquire db
|
|
|
|
// mutex, during that period, column family may become empty (e.g. its
|
|
|
|
// flush succeeds), then it affects the computed min_log_number_to_keep,
|
|
|
|
// so we take a snapshot for consistency of column family data
|
|
|
|
// status. If a column family becomes non-empty afterwards, its active log
|
|
|
|
// should still be the created new log, so the min_log_number_to_keep is
|
|
|
|
// not affected.
|
|
|
|
autovector<ColumnFamilyData*> empty_cfs;
|
|
|
|
for (auto cf : *versions_->GetColumnFamilySet()) {
|
|
|
|
if (cf->IsEmpty()) {
|
|
|
|
empty_cfs.push_back(cf);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
VersionEdit wal_deletion;
|
|
|
|
wal_deletion.DeleteWalsBefore(min_wal_number_to_keep);
|
|
|
|
s = versions_->LogAndApplyToDefaultColumnFamily(&wal_deletion, &mutex_);
|
|
|
|
if (!s.ok() && versions_->io_status().IsIOError()) {
|
|
|
|
s = error_handler_.SetBGError(versions_->io_status(),
|
|
|
|
BackgroundErrorReason::kManifestWrite);
|
|
|
|
}
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (auto cf : empty_cfs) {
|
|
|
|
if (cf->IsEmpty()) {
|
|
|
|
cf->SetLogNumber(logfile_number_);
|
Memtable "MemPurge" prototype (#8454)
Summary:
Implement an experimental feature called "MemPurge", which consists in purging "garbage" bytes out of a memtable and reuse the memtable struct instead of making it immutable and eventually flushing its content to storage.
The prototype is by default deactivated and is not intended for use. It is intended for correctness and validation testing. At the moment, the "MemPurge" feature can be switched on by using the `options.experimental_allow_mempurge` flag. For this early stage, when the allow_mempurge flag is set to `true`, all the flush operations will be rerouted to perform a MemPurge. This is a temporary design decision that will give us the time to explore meaningful heuristics to use MemPurge at the right time for relevant workloads . Moreover, the current MemPurge operation only supports `Puts`, `Deletes`, `DeleteRange` operations, and handles `Iterators` as well as `CompactionFilter`s that are invoked at flush time .
Three unit tests are added to `db_flush_test.cc` to test if MemPurge works correctly (and checks that the previously mentioned operations are fully supported thoroughly tested).
One noticeable design decision is the timing of the MemPurge operation in the memtable workflow: for this prototype, the mempurge happens when the memtable is switched (and usually made immutable). This is an inefficient process because it implies that the entirety of the MemPurge operation happens while holding the db_mutex. Future commits will make the MemPurge operation a background task (akin to the regular flush operation) and aim at drastically enhancing the performance of this operation. The MemPurge is also not fully "WAL-compatible" yet, but when the WAL is full, or when the regular MemPurge operation fails (or when the purged memtable still needs to be flushed), a regular flush operation takes place. Later commits will also correct these behaviors.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8454
Reviewed By: anand1976
Differential Revision: D29433971
Pulled By: bjlemaire
fbshipit-source-id: 6af48213554e35048a7e03816955100a80a26dc5
2021-07-02 14:22:03 +02:00
|
|
|
// MEMPURGE: No need to change this, because new adds
|
|
|
|
// should still receive new sequence numbers.
|
Track WAL obsoletion when updating empty CF's log number (#7781)
Summary:
In the write path, there is an optimization: when a new WAL is created during SwitchMemtable, we update the internal log number of the empty column families to the new WAL. `FindObsoleteFiles` marks a WAL as obsolete if the WAL's log number is less than `VersionSet::MinLogNumberWithUnflushedData`. After updating the empty column families' internal log number, `VersionSet::MinLogNumberWithUnflushedData` might change, so some WALs might become obsolete to be purged from disk.
For example, consider there are 3 column families: 0, 1, 2:
1. initially, all the column families' log number is 1;
2. write some data to cf0, and flush cf0, but the flush is pending;
3. now a new WAL 2 is created;
4. write data to cf1 and WAL 2, now cf0's log number is 1, cf1's log number is 2, cf2's log number is 2 (because cf1 and cf2 are empty, so their log numbers will be set to the highest log number);
5. now cf0's flush hasn't finished, flush cf1, a new WAL 3 is created, and cf1's flush finishes, now cf0's log number is 1, cf1's log number is 3, cf2's log number is 3, since WAL 1 still contains data for the unflushed cf0, no WAL can be deleted from disk;
6. now cf0's flush finishes, cf0's log number is 2 (because when cf0 was switching memtable, WAL 3 does not exist yet), cf1's log number is 3, cf2's log number is 3, so WAL 1 can be purged from disk now, but WAL 2 still cannot because `MinLogNumberToKeep()` is 2;
7. write data to cf2 and WAL 3, because cf0 is empty, its log number is updated to 3, so now cf0's log number is 3, cf1's log number is 3, cf2's log number is 3;
8. now if the background threads want to purge obsolete files from disk, WAL 2 can be purged because `MinLogNumberToKeep()` is 3. But there are only two flush results written to MANIFEST: the first is for flushing cf1, and the `MinLogNumberToKeep` is 1, the second is for flushing cf0, and the `MinLogNumberToKeep` is 2. So without this PR, if the DB crashes at this point and try to recover, `WalSet` will still expect WAL 2 to exist.
When WAL tracking is enabled, we assume WALs will only become obsolete after a flush result is written to MANIFEST in `MemtableList::TryInstallMemtableFlushResults` (or its atomic flush counterpart). The above situation breaks this assumption.
This PR tracks WAL obsoletion if necessary before updating the empty column families' log numbers.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7781
Test Plan:
watch existing tests and stress tests to pass.
`make -j48 blackbox_crash_test` on devserver
Reviewed By: ltamasi
Differential Revision: D25631695
Pulled By: cheng-chang
fbshipit-source-id: ca7fff967bdb42204b84226063d909893bc0a4ec
2020-12-19 06:33:20 +01:00
|
|
|
cf->mem()->SetCreationSeq(versions_->LastSequence());
|
|
|
|
} // cf may become non-empty.
|
|
|
|
}
|
|
|
|
empty_cf_updated = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (!empty_cf_updated) {
|
|
|
|
for (auto cf : *versions_->GetColumnFamilySet()) {
|
|
|
|
// all this is just optimization to delete logs that
|
|
|
|
// are no longer needed -- if CF is empty, that means it
|
|
|
|
// doesn't need that particular log to stay alive, so we just
|
|
|
|
// advance the log number. no need to persist this in the manifest
|
|
|
|
if (cf->IsEmpty()) {
|
|
|
|
if (creating_new_log) {
|
|
|
|
cf->SetLogNumber(logfile_number_);
|
|
|
|
}
|
|
|
|
cf->mem()->SetCreationSeq(versions_->LastSequence());
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
cfd->mem()->SetNextLogNumber(logfile_number_);
|
2021-07-07 03:47:59 +02:00
|
|
|
assert(new_mem != nullptr);
|
Make mempurge a background process (equivalent to in-memory compaction). (#8505)
Summary:
In https://github.com/facebook/rocksdb/issues/8454, I introduced a new process baptized `MemPurge` (memtable garbage collection). This new PR is built upon this past mempurge prototype.
In this PR, I made the `mempurge` process a background task, which provides superior performance since the mempurge process does not cling on the db_mutex anymore, and addresses severe restrictions from the past iteration (including a scenario where the past mempurge was failling, when a memtable was mempurged but was still referred to by an iterator/snapshot/...).
Now the mempurge process ressembles an in-memory compaction process: the stack of immutable memtables is filtered out, and the useful payload is used to populate an output memtable. If the output memtable is filled at more than 60% capacity (arbitrary heuristic) the mempurge process is aborted and a regular flush process takes place, else the output memtable is kept in the immutable memtable stack. Note that adding this output memtable to the `imm()` memtable stack does not trigger another flush process, so that the flush thread can go to sleep at the end of a successful mempurge.
MemPurge is activated by making the `experimental_allow_mempurge` flag `true`. When activated, the `MemPurge` process will always happen when the flush reason is `kWriteBufferFull`.
The 3 unit tests confirm that this process supports `Put`, `Get`, `Delete`, `DeleteRange` operators and is compatible with `Iterators` and `CompactionFilters`.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8505
Reviewed By: pdillinger
Differential Revision: D29619283
Pulled By: bjlemaire
fbshipit-source-id: 8a99bee76b63a8211bff1a00e0ae32360aaece95
2021-07-10 02:16:00 +02:00
|
|
|
cfd->imm()->Add(cfd->mem(), &context->memtables_to_free_);
|
2017-04-06 02:14:05 +02:00
|
|
|
new_mem->Ref();
|
|
|
|
cfd->SetMemtable(new_mem);
|
2017-10-06 03:00:38 +02:00
|
|
|
InstallSuperVersionAndScheduleWork(cfd, &context->superversion_context,
|
Make mempurge a background process (equivalent to in-memory compaction). (#8505)
Summary:
In https://github.com/facebook/rocksdb/issues/8454, I introduced a new process baptized `MemPurge` (memtable garbage collection). This new PR is built upon this past mempurge prototype.
In this PR, I made the `mempurge` process a background task, which provides superior performance since the mempurge process does not cling on the db_mutex anymore, and addresses severe restrictions from the past iteration (including a scenario where the past mempurge was failling, when a memtable was mempurged but was still referred to by an iterator/snapshot/...).
Now the mempurge process ressembles an in-memory compaction process: the stack of immutable memtables is filtered out, and the useful payload is used to populate an output memtable. If the output memtable is filled at more than 60% capacity (arbitrary heuristic) the mempurge process is aborted and a regular flush process takes place, else the output memtable is kept in the immutable memtable stack. Note that adding this output memtable to the `imm()` memtable stack does not trigger another flush process, so that the flush thread can go to sleep at the end of a successful mempurge.
MemPurge is activated by making the `experimental_allow_mempurge` flag `true`. When activated, the `MemPurge` process will always happen when the flush reason is `kWriteBufferFull`.
The 3 unit tests confirm that this process supports `Put`, `Get`, `Delete`, `DeleteRange` operators and is compatible with `Iterators` and `CompactionFilters`.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8505
Reviewed By: pdillinger
Differential Revision: D29619283
Pulled By: bjlemaire
fbshipit-source-id: 8a99bee76b63a8211bff1a00e0ae32360aaece95
2021-07-10 02:16:00 +02:00
|
|
|
mutable_cf_options);
|
Memtable "MemPurge" prototype (#8454)
Summary:
Implement an experimental feature called "MemPurge", which consists in purging "garbage" bytes out of a memtable and reuse the memtable struct instead of making it immutable and eventually flushing its content to storage.
The prototype is by default deactivated and is not intended for use. It is intended for correctness and validation testing. At the moment, the "MemPurge" feature can be switched on by using the `options.experimental_allow_mempurge` flag. For this early stage, when the allow_mempurge flag is set to `true`, all the flush operations will be rerouted to perform a MemPurge. This is a temporary design decision that will give us the time to explore meaningful heuristics to use MemPurge at the right time for relevant workloads . Moreover, the current MemPurge operation only supports `Puts`, `Deletes`, `DeleteRange` operations, and handles `Iterators` as well as `CompactionFilter`s that are invoked at flush time .
Three unit tests are added to `db_flush_test.cc` to test if MemPurge works correctly (and checks that the previously mentioned operations are fully supported thoroughly tested).
One noticeable design decision is the timing of the MemPurge operation in the memtable workflow: for this prototype, the mempurge happens when the memtable is switched (and usually made immutable). This is an inefficient process because it implies that the entirety of the MemPurge operation happens while holding the db_mutex. Future commits will make the MemPurge operation a background task (akin to the regular flush operation) and aim at drastically enhancing the performance of this operation. The MemPurge is also not fully "WAL-compatible" yet, but when the WAL is full, or when the regular MemPurge operation fails (or when the purged memtable still needs to be flushed), a regular flush operation takes place. Later commits will also correct these behaviors.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/8454
Reviewed By: anand1976
Differential Revision: D29433971
Pulled By: bjlemaire
fbshipit-source-id: 6af48213554e35048a7e03816955100a80a26dc5
2021-07-02 14:22:03 +02:00
|
|
|
|
2019-03-15 23:15:01 +01:00
|
|
|
#ifndef ROCKSDB_LITE
|
|
|
|
mutex_.Unlock();
|
|
|
|
// Notify client that memtable is sealed, now that we have successfully
|
|
|
|
// installed a new memtable
|
|
|
|
NotifyOnMemTableSealed(cfd, memtable_info);
|
|
|
|
mutex_.Lock();
|
|
|
|
#endif // ROCKSDB_LITE
|
2020-09-17 00:45:30 +02:00
|
|
|
// It is possible that we got here without checking the value of i_os, but
|
|
|
|
// that is okay. If we did, it most likely means that s was already an error.
|
|
|
|
// In any case, ignore any unchecked error for i_os here.
|
|
|
|
io_s.PermitUncheckedError();
|
2017-04-06 02:14:05 +02:00
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t DBImpl::GetWalPreallocateBlockSize(uint64_t write_buffer_size) const {
|
|
|
|
mutex_.AssertHeld();
|
2019-03-28 00:13:08 +01:00
|
|
|
size_t bsize =
|
|
|
|
static_cast<size_t>(write_buffer_size / 10 + write_buffer_size);
|
2017-04-06 02:14:05 +02:00
|
|
|
// Some users might set very high write_buffer_size and rely on
|
|
|
|
// max_total_wal_size or other parameters to control the WAL size.
|
|
|
|
if (mutable_db_options_.max_total_wal_size > 0) {
|
2019-03-28 00:13:08 +01:00
|
|
|
bsize = std::min<size_t>(
|
|
|
|
bsize, static_cast<size_t>(mutable_db_options_.max_total_wal_size));
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
if (immutable_db_options_.db_write_buffer_size > 0) {
|
|
|
|
bsize = std::min<size_t>(bsize, immutable_db_options_.db_write_buffer_size);
|
|
|
|
}
|
|
|
|
if (immutable_db_options_.write_buffer_manager &&
|
|
|
|
immutable_db_options_.write_buffer_manager->enabled()) {
|
|
|
|
bsize = std::min<size_t>(
|
|
|
|
bsize, immutable_db_options_.write_buffer_manager->buffer_size());
|
|
|
|
}
|
|
|
|
|
|
|
|
return bsize;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Default implementations of convenience methods that subclasses of DB
|
|
|
|
// can call if they wish
|
|
|
|
Status DB::Put(const WriteOptions& opt, ColumnFamilyHandle* column_family,
|
|
|
|
const Slice& key, const Slice& value) {
|
2019-06-06 08:07:28 +02:00
|
|
|
if (nullptr == opt.timestamp) {
|
|
|
|
// Pre-allocate size of write batch conservatively.
|
|
|
|
// 8 bytes are taken by header, 4 bytes for count, 1 byte for type,
|
|
|
|
// and we allocate 11 extra bytes for key length, as well as value length.
|
|
|
|
WriteBatch batch(key.size() + value.size() + 24);
|
|
|
|
Status s = batch.Put(column_family, key, value);
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
return Write(opt, &batch);
|
|
|
|
}
|
2019-07-26 00:23:46 +02:00
|
|
|
const Slice* ts = opt.timestamp;
|
|
|
|
assert(nullptr != ts);
|
|
|
|
size_t ts_sz = ts->size();
|
2020-04-28 07:47:44 +02:00
|
|
|
assert(column_family->GetComparator());
|
|
|
|
assert(ts_sz == column_family->GetComparator()->timestamp_size());
|
2021-09-13 00:33:15 +02:00
|
|
|
WriteBatch batch;
|
|
|
|
Status s;
|
|
|
|
if (key.data() + key.size() == ts->data()) {
|
|
|
|
Slice key_with_ts = Slice(key.data(), key.size() + ts_sz);
|
|
|
|
s = batch.Put(column_family, key_with_ts, value);
|
|
|
|
} else {
|
|
|
|
std::array<Slice, 2> key_with_ts_slices{{key, *ts}};
|
|
|
|
SliceParts key_with_ts(key_with_ts_slices.data(), 2);
|
|
|
|
std::array<Slice, 1> value_slices{{value}};
|
|
|
|
SliceParts values(value_slices.data(), 1);
|
|
|
|
s = batch.Put(column_family, key_with_ts, values);
|
2019-06-06 08:07:28 +02:00
|
|
|
}
|
2018-02-09 23:50:09 +01:00
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
return Write(opt, &batch);
|
|
|
|
}
|
|
|
|
|
|
|
|
Status DB::Delete(const WriteOptions& opt, ColumnFamilyHandle* column_family,
|
|
|
|
const Slice& key) {
|
2020-05-28 19:37:57 +02:00
|
|
|
if (nullptr == opt.timestamp) {
|
|
|
|
WriteBatch batch;
|
|
|
|
Status s = batch.Delete(column_family, key);
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
return Write(opt, &batch);
|
|
|
|
}
|
|
|
|
const Slice* ts = opt.timestamp;
|
|
|
|
assert(ts != nullptr);
|
2021-09-13 00:33:15 +02:00
|
|
|
size_t ts_sz = ts->size();
|
|
|
|
assert(column_family->GetComparator());
|
|
|
|
assert(ts_sz == column_family->GetComparator()->timestamp_size());
|
|
|
|
WriteBatch batch;
|
|
|
|
Status s;
|
|
|
|
if (key.data() + key.size() == ts->data()) {
|
|
|
|
Slice key_with_ts = Slice(key.data(), key.size() + ts_sz);
|
|
|
|
s = batch.Delete(column_family, key_with_ts);
|
|
|
|
} else {
|
|
|
|
std::array<Slice, 2> key_with_ts_slices{{key, *ts}};
|
|
|
|
SliceParts key_with_ts(key_with_ts_slices.data(), 2);
|
|
|
|
s = batch.Delete(column_family, key_with_ts);
|
2020-05-28 19:37:57 +02:00
|
|
|
}
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
return Write(opt, &batch);
|
|
|
|
}
|
|
|
|
|
|
|
|
Status DB::SingleDelete(const WriteOptions& opt,
|
|
|
|
ColumnFamilyHandle* column_family, const Slice& key) {
|
2021-09-27 20:49:35 +02:00
|
|
|
Status s;
|
|
|
|
if (opt.timestamp == nullptr) {
|
|
|
|
WriteBatch batch;
|
|
|
|
s = batch.SingleDelete(column_family, key);
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
s = Write(opt, &batch);
|
|
|
|
return s;
|
|
|
|
}
|
|
|
|
|
|
|
|
const Slice* ts = opt.timestamp;
|
|
|
|
assert(ts != nullptr);
|
|
|
|
size_t ts_sz = ts->size();
|
|
|
|
assert(column_family->GetComparator());
|
|
|
|
assert(ts_sz == column_family->GetComparator()->timestamp_size());
|
2017-04-06 02:14:05 +02:00
|
|
|
WriteBatch batch;
|
2021-09-27 20:49:35 +02:00
|
|
|
if (key.data() + key.size() == ts->data()) {
|
|
|
|
Slice key_with_ts = Slice(key.data(), key.size() + ts_sz);
|
|
|
|
s = batch.SingleDelete(column_family, key_with_ts);
|
|
|
|
} else {
|
|
|
|
std::array<Slice, 2> key_with_ts_slices{{key, *ts}};
|
|
|
|
SliceParts key_with_ts(key_with_ts_slices.data(), 2);
|
|
|
|
s = batch.SingleDelete(column_family, key_with_ts);
|
|
|
|
}
|
2020-09-29 18:47:33 +02:00
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
2021-09-27 20:49:35 +02:00
|
|
|
s = Write(opt, &batch);
|
|
|
|
return s;
|
2017-04-06 02:14:05 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
Status DB::DeleteRange(const WriteOptions& opt,
|
|
|
|
ColumnFamilyHandle* column_family,
|
|
|
|
const Slice& begin_key, const Slice& end_key) {
|
|
|
|
WriteBatch batch;
|
2020-09-29 18:47:33 +02:00
|
|
|
Status s = batch.DeleteRange(column_family, begin_key, end_key);
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
return Write(opt, &batch);
|
|
|
|
}
|
|
|
|
|
|
|
|
Status DB::Merge(const WriteOptions& opt, ColumnFamilyHandle* column_family,
|
|
|
|
const Slice& key, const Slice& value) {
|
|
|
|
WriteBatch batch;
|
2018-02-09 23:50:09 +01:00
|
|
|
Status s = batch.Merge(column_family, key, value);
|
|
|
|
if (!s.ok()) {
|
|
|
|
return s;
|
|
|
|
}
|
2017-04-06 02:14:05 +02:00
|
|
|
return Write(opt, &batch);
|
|
|
|
}
|
2020-02-20 21:07:53 +01:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|