2017-05-31 17:45:47 +00:00
|
|
|
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
2017-07-15 23:03:42 +00:00
|
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
|
|
// (found in the LICENSE.Apache file in the root directory).
|
2017-05-31 17:45:47 +00:00
|
|
|
|
2017-11-28 19:40:40 +00:00
|
|
|
#include <atomic>
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
#include <cstdint>
|
2020-07-09 21:33:42 +00:00
|
|
|
#include <fstream>
|
2017-05-31 17:45:47 +00:00
|
|
|
#include <memory>
|
|
|
|
#include <thread>
|
|
|
|
#include <vector>
|
2020-07-09 21:33:42 +00:00
|
|
|
|
2017-05-31 17:45:47 +00:00
|
|
|
#include "db/db_test_util.h"
|
|
|
|
#include "db/write_batch_internal.h"
|
2017-11-28 19:40:40 +00:00
|
|
|
#include "db/write_thread.h"
|
|
|
|
#include "port/port.h"
|
2017-05-31 17:45:47 +00:00
|
|
|
#include "port/stack_trace.h"
|
2019-05-30 18:21:38 +00:00
|
|
|
#include "test_util/sync_point.h"
|
2020-07-09 21:33:42 +00:00
|
|
|
#include "util/random.h"
|
2019-05-31 00:39:43 +00:00
|
|
|
#include "util/string_util.h"
|
2020-07-09 21:33:42 +00:00
|
|
|
#include "utilities/fault_injection_env.h"
|
2023-03-05 16:21:16 +00:00
|
|
|
#include "utilities/fault_injection_fs.h"
|
2017-05-31 17:45:47 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
namespace ROCKSDB_NAMESPACE {
|
2017-05-31 17:45:47 +00:00
|
|
|
|
|
|
|
// Test variations of WriteImpl.
|
|
|
|
class DBWriteTest : public DBTestBase, public testing::WithParamInterface<int> {
|
|
|
|
public:
|
2021-07-23 15:37:27 +00:00
|
|
|
DBWriteTest() : DBTestBase("db_write_test", /*env_do_fsync=*/true) {}
|
2017-05-31 17:45:47 +00:00
|
|
|
|
2017-11-28 19:40:40 +00:00
|
|
|
Options GetOptions() { return DBTestBase::GetOptions(GetParam()); }
|
|
|
|
|
|
|
|
void Open() { DBTestBase::Reopen(GetOptions()); }
|
2017-05-31 17:45:47 +00:00
|
|
|
};
|
|
|
|
|
2022-08-02 21:52:10 +00:00
|
|
|
class DBWriteTestUnparameterized : public DBTestBase {
|
|
|
|
public:
|
|
|
|
explicit DBWriteTestUnparameterized()
|
|
|
|
: DBTestBase("pipelined_write_test", /*env_do_fsync=*/false) {}
|
|
|
|
};
|
|
|
|
|
2017-10-29 04:56:50 +00:00
|
|
|
// It is invalid to do sync write while disabling WAL.
|
|
|
|
TEST_P(DBWriteTest, SyncAndDisableWAL) {
|
|
|
|
WriteOptions write_options;
|
|
|
|
write_options.sync = true;
|
|
|
|
write_options.disableWAL = true;
|
|
|
|
ASSERT_TRUE(dbfull()->Put(write_options, "foo", "bar").IsInvalidArgument());
|
|
|
|
WriteBatch batch;
|
|
|
|
ASSERT_OK(batch.Put("foo", "bar"));
|
|
|
|
ASSERT_TRUE(dbfull()->Write(write_options, &batch).IsInvalidArgument());
|
|
|
|
}
|
|
|
|
|
2020-10-06 19:42:57 +00:00
|
|
|
TEST_P(DBWriteTest, WriteStallRemoveNoSlowdownWrite) {
|
|
|
|
Options options = GetOptions();
|
|
|
|
options.level0_stop_writes_trigger = options.level0_slowdown_writes_trigger =
|
|
|
|
4;
|
|
|
|
std::vector<port::Thread> threads;
|
|
|
|
std::atomic<int> thread_num(0);
|
|
|
|
port::Mutex mutex;
|
|
|
|
port::CondVar cv(&mutex);
|
|
|
|
// Guarded by mutex
|
|
|
|
int writers = 0;
|
|
|
|
|
|
|
|
Reopen(options);
|
|
|
|
|
|
|
|
std::function<void()> write_slowdown_func = [&]() {
|
|
|
|
int a = thread_num.fetch_add(1);
|
|
|
|
std::string key = "foo" + std::to_string(a);
|
|
|
|
WriteOptions wo;
|
|
|
|
wo.no_slowdown = false;
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_OK(dbfull()->Put(wo, key, "bar"));
|
2020-10-06 19:42:57 +00:00
|
|
|
};
|
|
|
|
std::function<void()> write_no_slowdown_func = [&]() {
|
|
|
|
int a = thread_num.fetch_add(1);
|
|
|
|
std::string key = "foo" + std::to_string(a);
|
|
|
|
WriteOptions wo;
|
|
|
|
wo.no_slowdown = true;
|
2020-12-22 23:08:17 +00:00
|
|
|
Status s = dbfull()->Put(wo, key, "bar");
|
|
|
|
ASSERT_TRUE(s.ok() || s.IsIncomplete());
|
2020-10-06 19:42:57 +00:00
|
|
|
};
|
|
|
|
std::function<void(void*)> unblock_main_thread_func = [&](void*) {
|
|
|
|
mutex.Lock();
|
|
|
|
++writers;
|
|
|
|
cv.SignalAll();
|
|
|
|
mutex.Unlock();
|
|
|
|
};
|
|
|
|
|
|
|
|
// Create 3 L0 files and schedule 4th without waiting
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_OK(Put("foo" + std::to_string(thread_num.fetch_add(1)), "bar"));
|
|
|
|
ASSERT_OK(Flush());
|
|
|
|
ASSERT_OK(Put("foo" + std::to_string(thread_num.fetch_add(1)), "bar"));
|
|
|
|
ASSERT_OK(Flush());
|
|
|
|
ASSERT_OK(Put("foo" + std::to_string(thread_num.fetch_add(1)), "bar"));
|
|
|
|
ASSERT_OK(Flush());
|
|
|
|
ASSERT_OK(Put("foo" + std::to_string(thread_num.fetch_add(1)), "bar"));
|
2020-10-06 19:42:57 +00:00
|
|
|
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->SetCallBack(
|
|
|
|
"WriteThread::JoinBatchGroup:Start", unblock_main_thread_func);
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->LoadDependency(
|
|
|
|
{{"DBWriteTest::WriteStallRemoveNoSlowdownWrite:1",
|
|
|
|
"DBImpl::BackgroundCallFlush:start"},
|
|
|
|
{"DBWriteTest::WriteStallRemoveNoSlowdownWrite:2",
|
|
|
|
"DBImplWrite::PipelinedWriteImpl:AfterJoinBatchGroup"},
|
|
|
|
// Make compaction start wait for the write stall to be detected and
|
|
|
|
// implemented by a write group leader
|
|
|
|
{"DBWriteTest::WriteStallRemoveNoSlowdownWrite:3",
|
|
|
|
"BackgroundCallCompaction:0"}});
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->EnableProcessing();
|
|
|
|
|
|
|
|
// Schedule creation of 4th L0 file without waiting. This will seal the
|
|
|
|
// memtable and then wait for a sync point before writing the file. We need
|
|
|
|
// to do it this way because SwitchMemtable() needs to enter the
|
|
|
|
// write_thread
|
|
|
|
FlushOptions fopt;
|
|
|
|
fopt.wait = false;
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_OK(dbfull()->Flush(fopt));
|
2020-10-06 19:42:57 +00:00
|
|
|
|
|
|
|
// Create a mix of slowdown/no_slowdown write threads
|
|
|
|
mutex.Lock();
|
|
|
|
// First leader
|
|
|
|
threads.emplace_back(write_slowdown_func);
|
|
|
|
while (writers != 1) {
|
|
|
|
cv.Wait();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Second leader. Will stall writes
|
|
|
|
// Build a writers list with no slowdown in the middle:
|
|
|
|
// +-------------+
|
|
|
|
// | slowdown +<----+ newest
|
|
|
|
// +--+----------+
|
|
|
|
// |
|
|
|
|
// v
|
|
|
|
// +--+----------+
|
|
|
|
// | no slowdown |
|
|
|
|
// +--+----------+
|
|
|
|
// |
|
|
|
|
// v
|
|
|
|
// +--+----------+
|
|
|
|
// | slowdown +
|
|
|
|
// +-------------+
|
|
|
|
threads.emplace_back(write_slowdown_func);
|
|
|
|
while (writers != 2) {
|
|
|
|
cv.Wait();
|
|
|
|
}
|
|
|
|
threads.emplace_back(write_no_slowdown_func);
|
|
|
|
while (writers != 3) {
|
|
|
|
cv.Wait();
|
|
|
|
}
|
|
|
|
threads.emplace_back(write_slowdown_func);
|
|
|
|
while (writers != 4) {
|
|
|
|
cv.Wait();
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex.Unlock();
|
|
|
|
|
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteStallRemoveNoSlowdownWrite:1");
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_OK(dbfull()->TEST_WaitForFlushMemTable(nullptr));
|
2020-10-06 19:42:57 +00:00
|
|
|
// This would have triggered a write stall. Unblock the write group leader
|
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteStallRemoveNoSlowdownWrite:2");
|
|
|
|
// The leader is going to create missing newer links. When the leader
|
|
|
|
// finishes, the next leader is going to delay writes and fail writers with
|
|
|
|
// no_slowdown
|
|
|
|
|
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteStallRemoveNoSlowdownWrite:3");
|
|
|
|
for (auto& t : threads) {
|
|
|
|
t.join();
|
|
|
|
}
|
|
|
|
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->DisableProcessing();
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->ClearAllCallBacks();
|
|
|
|
}
|
|
|
|
|
2020-01-23 21:59:48 +00:00
|
|
|
TEST_P(DBWriteTest, WriteThreadHangOnWriteStall) {
|
|
|
|
Options options = GetOptions();
|
2022-11-02 21:34:24 +00:00
|
|
|
options.level0_stop_writes_trigger = options.level0_slowdown_writes_trigger =
|
|
|
|
4;
|
2020-01-23 21:59:48 +00:00
|
|
|
std::vector<port::Thread> threads;
|
|
|
|
std::atomic<int> thread_num(0);
|
|
|
|
port::Mutex mutex;
|
|
|
|
port::CondVar cv(&mutex);
|
2020-09-22 16:55:42 +00:00
|
|
|
// Guarded by mutex
|
|
|
|
int writers = 0;
|
2020-01-23 21:59:48 +00:00
|
|
|
|
|
|
|
Reopen(options);
|
|
|
|
|
|
|
|
std::function<void()> write_slowdown_func = [&]() {
|
|
|
|
int a = thread_num.fetch_add(1);
|
|
|
|
std::string key = "foo" + std::to_string(a);
|
|
|
|
WriteOptions wo;
|
|
|
|
wo.no_slowdown = false;
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_OK(dbfull()->Put(wo, key, "bar"));
|
2020-01-23 21:59:48 +00:00
|
|
|
};
|
|
|
|
std::function<void()> write_no_slowdown_func = [&]() {
|
|
|
|
int a = thread_num.fetch_add(1);
|
|
|
|
std::string key = "foo" + std::to_string(a);
|
|
|
|
WriteOptions wo;
|
|
|
|
wo.no_slowdown = true;
|
2020-12-22 23:08:17 +00:00
|
|
|
Status s = dbfull()->Put(wo, key, "bar");
|
|
|
|
ASSERT_TRUE(s.ok() || s.IsIncomplete());
|
2020-01-23 21:59:48 +00:00
|
|
|
};
|
2022-11-02 21:34:24 +00:00
|
|
|
std::function<void(void*)> unblock_main_thread_func = [&](void*) {
|
2020-01-23 21:59:48 +00:00
|
|
|
mutex.Lock();
|
2020-09-22 16:55:42 +00:00
|
|
|
++writers;
|
2020-01-23 21:59:48 +00:00
|
|
|
cv.SignalAll();
|
|
|
|
mutex.Unlock();
|
|
|
|
};
|
|
|
|
|
|
|
|
// Create 3 L0 files and schedule 4th without waiting
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_OK(Put("foo" + std::to_string(thread_num.fetch_add(1)), "bar"));
|
|
|
|
ASSERT_OK(Flush());
|
|
|
|
ASSERT_OK(Put("foo" + std::to_string(thread_num.fetch_add(1)), "bar"));
|
|
|
|
ASSERT_OK(Flush());
|
|
|
|
ASSERT_OK(Put("foo" + std::to_string(thread_num.fetch_add(1)), "bar"));
|
|
|
|
ASSERT_OK(Flush());
|
|
|
|
ASSERT_OK(Put("foo" + std::to_string(thread_num.fetch_add(1)), "bar"));
|
2020-01-23 21:59:48 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->SetCallBack(
|
|
|
|
"WriteThread::JoinBatchGroup:Start", unblock_main_thread_func);
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->LoadDependency(
|
|
|
|
{{"DBWriteTest::WriteThreadHangOnWriteStall:1",
|
|
|
|
"DBImpl::BackgroundCallFlush:start"},
|
|
|
|
{"DBWriteTest::WriteThreadHangOnWriteStall:2",
|
|
|
|
"DBImpl::WriteImpl:BeforeLeaderEnters"},
|
|
|
|
// Make compaction start wait for the write stall to be detected and
|
|
|
|
// implemented by a write group leader
|
|
|
|
{"DBWriteTest::WriteThreadHangOnWriteStall:3",
|
|
|
|
"BackgroundCallCompaction:0"}});
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->EnableProcessing();
|
2020-01-23 21:59:48 +00:00
|
|
|
|
|
|
|
// Schedule creation of 4th L0 file without waiting. This will seal the
|
|
|
|
// memtable and then wait for a sync point before writing the file. We need
|
|
|
|
// to do it this way because SwitchMemtable() needs to enter the
|
|
|
|
// write_thread
|
|
|
|
FlushOptions fopt;
|
|
|
|
fopt.wait = false;
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_OK(dbfull()->Flush(fopt));
|
2020-01-23 21:59:48 +00:00
|
|
|
|
|
|
|
// Create a mix of slowdown/no_slowdown write threads
|
|
|
|
mutex.Lock();
|
|
|
|
// First leader
|
|
|
|
threads.emplace_back(write_slowdown_func);
|
2020-09-22 16:55:42 +00:00
|
|
|
while (writers != 1) {
|
|
|
|
cv.Wait();
|
|
|
|
}
|
2020-01-23 21:59:48 +00:00
|
|
|
// Second leader. Will stall writes
|
|
|
|
threads.emplace_back(write_slowdown_func);
|
|
|
|
threads.emplace_back(write_no_slowdown_func);
|
|
|
|
threads.emplace_back(write_slowdown_func);
|
|
|
|
threads.emplace_back(write_no_slowdown_func);
|
|
|
|
threads.emplace_back(write_slowdown_func);
|
2020-09-22 16:55:42 +00:00
|
|
|
while (writers != 6) {
|
|
|
|
cv.Wait();
|
|
|
|
}
|
2020-01-23 21:59:48 +00:00
|
|
|
mutex.Unlock();
|
|
|
|
|
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteThreadHangOnWriteStall:1");
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_OK(dbfull()->TEST_WaitForFlushMemTable(nullptr));
|
2020-01-23 21:59:48 +00:00
|
|
|
// This would have triggered a write stall. Unblock the write group leader
|
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteThreadHangOnWriteStall:2");
|
2022-11-02 21:34:24 +00:00
|
|
|
// The leader is going to create missing newer links. When the leader
|
|
|
|
// finishes, the next leader is going to delay writes and fail writers with
|
|
|
|
// no_slowdown
|
2020-01-23 21:59:48 +00:00
|
|
|
|
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteThreadHangOnWriteStall:3");
|
|
|
|
for (auto& t : threads) {
|
|
|
|
t.join();
|
|
|
|
}
|
2020-09-22 16:55:42 +00:00
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->DisableProcessing();
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->ClearAllCallBacks();
|
2020-01-23 21:59:48 +00:00
|
|
|
}
|
|
|
|
|
2024-02-22 20:14:53 +00:00
|
|
|
TEST_P(DBWriteTest, WriteThreadWaitNanosCounter) {
|
|
|
|
Options options = GetOptions();
|
|
|
|
std::vector<port::Thread> threads;
|
|
|
|
|
|
|
|
Reopen(options);
|
|
|
|
|
|
|
|
std::function<void()> write_func = [&]() {
|
|
|
|
PerfContext* perf_ctx = get_perf_context();
|
|
|
|
SetPerfLevel(PerfLevel::kEnableWait);
|
|
|
|
perf_ctx->Reset();
|
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteThreadWaitNanosCounter:WriteFunc");
|
|
|
|
ASSERT_OK(dbfull()->Put(WriteOptions(), "bar", "val2"));
|
Fix windows build and CI (#12426)
Summary:
Issue https://github.com/facebook/rocksdb/issues/12421 describes a regression in the migration from CircleCI to GitHub Actions in which failing build steps no longer fail Windows CI jobs. In GHA with pwsh (new preferred powershell command), only the last non-builtin command (or something like that) affects the overall success/failure result, and failures in external commands do not exit the script, even with `$ErrorActionPreference = 'Stop'` and `$PSNativeCommandErrorActionPreference = $true`. Switching to `powershell` causes some obscure failure (not seen in CircleCI) about the `-Lo` option to `curl`.
Here we work around this using the only reasonable-but-ugly way known: explicitly check the result after every non-trivial build step. This leaves us highly susceptible to future regressions with unchecked build steps in the future, but a clean solution is not known.
This change also fixes the build errors that were allowed to creep in because of the CI regression. Also decreased the unnecessarily long running time of DBWriteTest.WriteThreadWaitNanosCounter.
For background, this problem explicitly contradicts GitHub's documentation, and GitHub has known about the problem for more than a year, with no evidence of caring or intending to fix. https://github.com/actions/runner-images/issues/6668 Somehow CircleCI doesn't have this problem. And even though cmd.exe and powershell have been perpetuating DOS-isms for decades, they still seem to be a somewhat active "hot mess" when it comes to sensible, consistent, and documented behavior.
Fixes https://github.com/facebook/rocksdb/issues/12421
A history of some things I tried in development is here: https://github.com/facebook/rocksdb/compare/main...pdillinger:rocksdb:debug_windows_ci_orig
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12426
Test Plan: CI, including https://github.com/facebook/rocksdb/issues/12434 where I have temporarily enabled other Windows builds on PR with this change
Reviewed By: cbi42
Differential Revision: D54903698
Pulled By: pdillinger
fbshipit-source-id: 116bcbebbbf98f347c7cf7dfdeebeaaed7f76827
2024-03-14 19:04:41 +00:00
|
|
|
ASSERT_GT(perf_ctx->write_thread_wait_nanos, 2000000U);
|
2024-02-22 20:14:53 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
std::function<void()> sleep_func = [&]() {
|
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteThreadWaitNanosCounter:SleepFunc:1");
|
Fix windows build and CI (#12426)
Summary:
Issue https://github.com/facebook/rocksdb/issues/12421 describes a regression in the migration from CircleCI to GitHub Actions in which failing build steps no longer fail Windows CI jobs. In GHA with pwsh (new preferred powershell command), only the last non-builtin command (or something like that) affects the overall success/failure result, and failures in external commands do not exit the script, even with `$ErrorActionPreference = 'Stop'` and `$PSNativeCommandErrorActionPreference = $true`. Switching to `powershell` causes some obscure failure (not seen in CircleCI) about the `-Lo` option to `curl`.
Here we work around this using the only reasonable-but-ugly way known: explicitly check the result after every non-trivial build step. This leaves us highly susceptible to future regressions with unchecked build steps in the future, but a clean solution is not known.
This change also fixes the build errors that were allowed to creep in because of the CI regression. Also decreased the unnecessarily long running time of DBWriteTest.WriteThreadWaitNanosCounter.
For background, this problem explicitly contradicts GitHub's documentation, and GitHub has known about the problem for more than a year, with no evidence of caring or intending to fix. https://github.com/actions/runner-images/issues/6668 Somehow CircleCI doesn't have this problem. And even though cmd.exe and powershell have been perpetuating DOS-isms for decades, they still seem to be a somewhat active "hot mess" when it comes to sensible, consistent, and documented behavior.
Fixes https://github.com/facebook/rocksdb/issues/12421
A history of some things I tried in development is here: https://github.com/facebook/rocksdb/compare/main...pdillinger:rocksdb:debug_windows_ci_orig
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12426
Test Plan: CI, including https://github.com/facebook/rocksdb/issues/12434 where I have temporarily enabled other Windows builds on PR with this change
Reviewed By: cbi42
Differential Revision: D54903698
Pulled By: pdillinger
fbshipit-source-id: 116bcbebbbf98f347c7cf7dfdeebeaaed7f76827
2024-03-14 19:04:41 +00:00
|
|
|
SystemClock::Default()->SleepForMicroseconds(2000);
|
2024-02-22 20:14:53 +00:00
|
|
|
TEST_SYNC_POINT("DBWriteTest::WriteThreadWaitNanosCounter:SleepFunc:2");
|
|
|
|
};
|
|
|
|
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->LoadDependency(
|
|
|
|
{{"WriteThread::EnterAsBatchGroupLeader:End",
|
|
|
|
"DBWriteTest::WriteThreadWaitNanosCounter:WriteFunc"},
|
|
|
|
{"WriteThread::AwaitState:BlockingWaiting",
|
|
|
|
"DBWriteTest::WriteThreadWaitNanosCounter:SleepFunc:1"},
|
|
|
|
{"DBWriteTest::WriteThreadWaitNanosCounter:SleepFunc:2",
|
|
|
|
"WriteThread::ExitAsBatchGroupLeader:Start"}});
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->EnableProcessing();
|
|
|
|
|
|
|
|
threads.emplace_back(sleep_func);
|
|
|
|
threads.emplace_back(write_func);
|
|
|
|
|
|
|
|
ASSERT_OK(dbfull()->Put(WriteOptions(), "foo", "val1"));
|
|
|
|
|
|
|
|
for (auto& t : threads) {
|
|
|
|
t.join();
|
|
|
|
}
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->DisableProcessing();
|
|
|
|
}
|
|
|
|
|
2017-11-28 19:40:40 +00:00
|
|
|
TEST_P(DBWriteTest, IOErrorOnWALWritePropagateToWriteThreadFollower) {
|
|
|
|
constexpr int kNumThreads = 5;
|
|
|
|
std::unique_ptr<FaultInjectionTestEnv> mock_env(
|
Fix many tests to run with MEM_ENV and ENCRYPTED_ENV; Introduce a MemoryFileSystem class (#7566)
Summary:
This PR does a few things:
1. The MockFileSystem class was split out from the MockEnv. This change would theoretically allow a MockFileSystem to be used by other Environments as well (if we created a means of constructing one). The MockFileSystem implements a FileSystem in its entirety and does not rely on any Wrapper implementation.
2. Make the RocksDB test suite work when MOCK_ENV=1 and ENCRYPTED_ENV=1 are set. To accomplish this, a few things were needed:
- The tests that tried to use the "wrong" environment (Env::Default() instead of env_) were updated
- The MockFileSystem was changed to support the features it was missing or mishandled (such as recursively deleting files in a directory or supporting renaming of a directory).
3. Updated the test framework to have a ROCKSDB_GTEST_SKIP macro. This can be used to flag tests that are skipped. Currently, this defaults to doing nothing (marks the test as SUCCESS) but will mark the tests as SKIPPED when RocksDB is upgraded to a version of gtest that supports this (gtest-1.10).
I have run a full "make check" with MEM_ENV, ENCRYPTED_ENV, both, and neither under both MacOS and RedHat. A few tests were disabled/skipped for the MEM/ENCRYPTED cases. The error_handler_fs_test fails/hangs for MEM_ENV (presumably a timing problem) and I will introduce another PR/issue to track that problem. (I will also push a change to disable those tests soon). There is one more test in DBTest2 that also fails which I need to investigate or skip before this PR is merged.
Theoretically, this PR should also allow the test suite to run against an Env loaded from the registry, though I do not have one to try it with currently.
Finally, once this is accepted, it would be nice if there was a CircleCI job to run these tests on a checkin so this effort does not become stale. I do not know how to do that, so if someone could write that job, it would be appreciated :)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7566
Reviewed By: zhichao-cao
Differential Revision: D24408980
Pulled By: jay-zhuang
fbshipit-source-id: 911b1554a4d0da06fd51feca0c090a4abdcb4a5f
2020-10-27 17:31:34 +00:00
|
|
|
new FaultInjectionTestEnv(env_));
|
2017-11-28 19:40:40 +00:00
|
|
|
Options options = GetOptions();
|
|
|
|
options.env = mock_env.get();
|
|
|
|
Reopen(options);
|
|
|
|
std::atomic<int> ready_count{0};
|
|
|
|
std::atomic<int> leader_count{0};
|
|
|
|
std::vector<port::Thread> threads;
|
|
|
|
mock_env->SetFilesystemActive(false);
|
2018-05-14 17:53:32 +00:00
|
|
|
|
2017-11-28 19:40:40 +00:00
|
|
|
// Wait until all threads linked to write threads, to make sure
|
|
|
|
// all threads join the same batch group.
|
|
|
|
SyncPoint::GetInstance()->SetCallBack(
|
|
|
|
"WriteThread::JoinBatchGroup:Wait", [&](void* arg) {
|
|
|
|
ready_count++;
|
Prefer static_cast in place of most reinterpret_cast (#12308)
Summary:
The following are risks associated with pointer-to-pointer reinterpret_cast:
* Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do.
* Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally.
I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement:
* Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have
`struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic.
* Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance.
With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain.
A couple of related interventions included here:
* Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle.
* Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse).
Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work.
I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308
Test Plan: existing tests, CI
Reviewed By: ltamasi
Differential Revision: D53204947
Pulled By: pdillinger
fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2
2024-02-07 18:44:11 +00:00
|
|
|
auto* w = static_cast<WriteThread::Writer*>(arg);
|
2017-11-28 19:40:40 +00:00
|
|
|
if (w->state == WriteThread::STATE_GROUP_LEADER) {
|
|
|
|
leader_count++;
|
|
|
|
while (ready_count < kNumThreads) {
|
|
|
|
// busy waiting
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
SyncPoint::GetInstance()->EnableProcessing();
|
|
|
|
for (int i = 0; i < kNumThreads; i++) {
|
2024-01-05 19:53:57 +00:00
|
|
|
threads.emplace_back(
|
2017-11-28 19:40:40 +00:00
|
|
|
[&](int index) {
|
|
|
|
// All threads should fail.
|
2022-05-06 20:03:58 +00:00
|
|
|
auto res = Put("key" + std::to_string(index), "value");
|
2018-05-14 17:53:32 +00:00
|
|
|
if (options.manual_wal_flush) {
|
|
|
|
ASSERT_TRUE(res.ok());
|
|
|
|
// we should see fs error when we do the flush
|
2018-05-15 03:56:44 +00:00
|
|
|
|
|
|
|
// TSAN reports a false alarm for lock-order-inversion but Open and
|
|
|
|
// FlushWAL are not run concurrently. Disabling this until TSAN is
|
|
|
|
// fixed.
|
|
|
|
// res = dbfull()->FlushWAL(false);
|
|
|
|
// ASSERT_FALSE(res.ok());
|
|
|
|
} else {
|
|
|
|
ASSERT_FALSE(res.ok());
|
2018-05-14 17:53:32 +00:00
|
|
|
}
|
2017-11-28 19:40:40 +00:00
|
|
|
},
|
2024-01-05 19:53:57 +00:00
|
|
|
i);
|
2017-11-28 19:40:40 +00:00
|
|
|
}
|
|
|
|
for (int i = 0; i < kNumThreads; i++) {
|
|
|
|
threads[i].join();
|
|
|
|
}
|
|
|
|
ASSERT_EQ(1, leader_count);
|
2020-12-22 23:08:17 +00:00
|
|
|
|
|
|
|
// The Failed PUT operations can cause a BG error to be set.
|
|
|
|
// Mark it as Checked for the ASSERT_STATUS_CHECKED
|
|
|
|
dbfull()->Resume().PermitUncheckedError();
|
|
|
|
|
2017-11-28 19:40:40 +00:00
|
|
|
// Close before mock_env destruct.
|
|
|
|
Close();
|
|
|
|
}
|
|
|
|
|
2022-08-02 21:52:10 +00:00
|
|
|
TEST_F(DBWriteTestUnparameterized, PipelinedWriteRace) {
|
|
|
|
// This test was written to trigger a race in ExitAsBatchGroupLeader in case
|
|
|
|
// enable_pipelined_write_ was true.
|
|
|
|
// Writers for which ShouldWriteToMemtable() evaluates to false are removed
|
|
|
|
// from the write_group via CompleteFollower/ CompleteLeader. Writers in the
|
|
|
|
// middle of the group are fully unlinked, but if that writers is the
|
|
|
|
// last_writer, then we did not update the predecessor's link_older, i.e.,
|
|
|
|
// this writer was still reachable via newest_writer_.
|
|
|
|
//
|
|
|
|
// But the problem was, that CompleteFollower already wakes up the thread
|
|
|
|
// owning that writer before the writer has been removed. This resulted in a
|
|
|
|
// race - if the leader thread was fast enough, then everything was fine.
|
|
|
|
// However, if the woken up thread finished the current write operation and
|
|
|
|
// then performed yet another write, then a new writer instance was added
|
|
|
|
// to newest_writer_. It is possible that the new writer is located on the
|
|
|
|
// same address on stack, and if this happened, then we had a problem,
|
|
|
|
// because the old code tried to find the last_writer in the list to unlink
|
|
|
|
// it, which in this case produced a cycle in the list.
|
|
|
|
// Whether two invocations of PipelinedWriteImpl() by the same thread actually
|
|
|
|
// allocate the writer on the same address depends on the OS and/or compiler,
|
|
|
|
// so it is rather hard to create a deterministic test for this.
|
|
|
|
|
|
|
|
Options options = GetDefaultOptions();
|
|
|
|
options.create_if_missing = true;
|
|
|
|
options.enable_pipelined_write = true;
|
|
|
|
std::vector<port::Thread> threads;
|
|
|
|
|
|
|
|
std::atomic<int> write_counter{0};
|
|
|
|
std::atomic<int> active_writers{0};
|
|
|
|
std::atomic<bool> second_write_starting{false};
|
|
|
|
std::atomic<bool> second_write_in_progress{false};
|
|
|
|
std::atomic<WriteThread::Writer*> leader{nullptr};
|
|
|
|
std::atomic<bool> finished_WAL_write{false};
|
|
|
|
|
|
|
|
DestroyAndReopen(options);
|
|
|
|
|
|
|
|
auto write_one_doc = [&]() {
|
|
|
|
int a = write_counter.fetch_add(1);
|
|
|
|
std::string key = "foo" + std::to_string(a);
|
|
|
|
WriteOptions wo;
|
|
|
|
ASSERT_OK(dbfull()->Put(wo, key, "bar"));
|
|
|
|
--active_writers;
|
|
|
|
};
|
|
|
|
|
|
|
|
auto write_two_docs = [&]() {
|
|
|
|
write_one_doc();
|
|
|
|
second_write_starting = true;
|
|
|
|
write_one_doc();
|
|
|
|
};
|
|
|
|
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->SetCallBack(
|
|
|
|
"WriteThread::JoinBatchGroup:Wait", [&](void* arg) {
|
|
|
|
if (second_write_starting.load()) {
|
|
|
|
second_write_in_progress = true;
|
|
|
|
return;
|
|
|
|
}
|
Prefer static_cast in place of most reinterpret_cast (#12308)
Summary:
The following are risks associated with pointer-to-pointer reinterpret_cast:
* Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do.
* Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally.
I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement:
* Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have
`struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic.
* Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance.
With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain.
A couple of related interventions included here:
* Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle.
* Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse).
Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work.
I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308
Test Plan: existing tests, CI
Reviewed By: ltamasi
Differential Revision: D53204947
Pulled By: pdillinger
fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2
2024-02-07 18:44:11 +00:00
|
|
|
auto* w = static_cast<WriteThread::Writer*>(arg);
|
2022-08-02 21:52:10 +00:00
|
|
|
if (w->state == WriteThread::STATE_GROUP_LEADER) {
|
|
|
|
active_writers++;
|
|
|
|
if (leader.load() == nullptr) {
|
|
|
|
leader.store(w);
|
|
|
|
while (active_writers.load() < 2) {
|
|
|
|
// wait for another thread to join the write_group
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
// we disable the memtable for all followers so that they they are
|
|
|
|
// removed from the write_group before enqueuing it for the memtable
|
|
|
|
// write
|
|
|
|
w->disable_memtable = true;
|
|
|
|
active_writers++;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->SetCallBack(
|
|
|
|
"WriteThread::ExitAsBatchGroupLeader:Start", [&](void* arg) {
|
Prefer static_cast in place of most reinterpret_cast (#12308)
Summary:
The following are risks associated with pointer-to-pointer reinterpret_cast:
* Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do.
* Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally.
I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement:
* Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have
`struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic.
* Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance.
With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain.
A couple of related interventions included here:
* Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle.
* Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse).
Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work.
I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308
Test Plan: existing tests, CI
Reviewed By: ltamasi
Differential Revision: D53204947
Pulled By: pdillinger
fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2
2024-02-07 18:44:11 +00:00
|
|
|
auto* wg = static_cast<WriteThread::WriteGroup*>(arg);
|
2022-08-02 21:52:10 +00:00
|
|
|
if (wg->leader == leader && !finished_WAL_write) {
|
|
|
|
finished_WAL_write = true;
|
|
|
|
while (active_writers.load() < 3) {
|
|
|
|
// wait for the new writer to be enqueued
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->SetCallBack(
|
|
|
|
"WriteThread::ExitAsBatchGroupLeader:AfterCompleteWriters",
|
|
|
|
[&](void* arg) {
|
Prefer static_cast in place of most reinterpret_cast (#12308)
Summary:
The following are risks associated with pointer-to-pointer reinterpret_cast:
* Can produce the "wrong result" (crash or memory corruption). IIRC, in theory this can happen for any up-cast or down-cast for a non-standard-layout type, though in practice would only happen for multiple inheritance cases (where the base class pointer might be "inside" the derived object). We don't use multiple inheritance a lot, but we do.
* Can mask useful compiler errors upon code change, including converting between unrelated pointer types that you are expecting to be related, and converting between pointer and scalar types unintentionally.
I can only think of some obscure cases where static_cast could be troublesome when it compiles as a replacement:
* Going through `void*` could plausibly cause unnecessary or broken pointer arithmetic. Suppose we have
`struct Derived: public Base1, public Base2`. If we have `Derived*` -> `void*` -> `Base2*` -> `Derived*` through reinterpret casts, this could plausibly work (though technical UB) assuming the `Base2*` is not dereferenced. Changing to static cast could introduce breaking pointer arithmetic.
* Unnecessary (but safe) pointer arithmetic could arise in a case like `Derived*` -> `Base2*` -> `Derived*` where before the Base2 pointer might not have been dereferenced. This could potentially affect performance.
With some light scripting, I tried replacing pointer-to-pointer reinterpret_casts with static_cast and kept the cases that still compile. Most occurrences of reinterpret_cast have successfully been changed (except for java/ and third-party/). 294 changed, 257 remain.
A couple of related interventions included here:
* Previously Cache::Handle was not actually derived from in the implementations and just used as a `void*` stand-in with reinterpret_cast. Now there is a relationship to allow static_cast. In theory, this could introduce pointer arithmetic (as described above) but is unlikely without multiple inheritance AND non-empty Cache::Handle.
* Remove some unnecessary casts to void* as this is allowed to be implicit (for better or worse).
Most of the remaining reinterpret_casts are for converting to/from raw bytes of objects. We could consider better idioms for these patterns in follow-up work.
I wish there were a way to implement a template variant of static_cast that would only compile if no pointer arithmetic is generated, but best I can tell, this is not possible. AFAIK the best you could do is a dynamic check that the void* conversion after the static cast is unchanged.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/12308
Test Plan: existing tests, CI
Reviewed By: ltamasi
Differential Revision: D53204947
Pulled By: pdillinger
fbshipit-source-id: 9de23e618263b0d5b9820f4e15966876888a16e2
2024-02-07 18:44:11 +00:00
|
|
|
auto* wg = static_cast<WriteThread::WriteGroup*>(arg);
|
2022-08-02 21:52:10 +00:00
|
|
|
if (wg->leader == leader) {
|
|
|
|
while (!second_write_in_progress.load()) {
|
|
|
|
// wait for the old follower thread to start the next write
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->EnableProcessing();
|
|
|
|
|
|
|
|
// start leader + one follower
|
|
|
|
threads.emplace_back(write_one_doc);
|
|
|
|
while (leader.load() == nullptr) {
|
|
|
|
// wait for leader
|
|
|
|
}
|
|
|
|
|
|
|
|
// we perform two writes in the follower, so that for the second write
|
|
|
|
// the thread reinserts a Writer with the same address
|
|
|
|
threads.emplace_back(write_two_docs);
|
|
|
|
|
|
|
|
// wait for the leader to enter ExitAsBatchGroupLeader
|
|
|
|
while (!finished_WAL_write.load()) {
|
|
|
|
// wait for write_group to have finished the WAL writes
|
|
|
|
}
|
|
|
|
|
|
|
|
// start another writer thread to be enqueued before the leader can
|
|
|
|
// complete the writers from its write_group
|
|
|
|
threads.emplace_back(write_one_doc);
|
|
|
|
|
|
|
|
for (auto& t : threads) {
|
|
|
|
t.join();
|
|
|
|
}
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->DisableProcessing();
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->ClearAllCallBacks();
|
|
|
|
}
|
|
|
|
|
2018-05-14 17:53:32 +00:00
|
|
|
TEST_P(DBWriteTest, ManualWalFlushInEffect) {
|
|
|
|
Options options = GetOptions();
|
|
|
|
Reopen(options);
|
|
|
|
// try the 1st WAL created during open
|
2022-05-06 20:03:58 +00:00
|
|
|
ASSERT_TRUE(Put("key" + std::to_string(0), "value").ok());
|
Add manual_wal_flush, FlushWAL() to stress/crash test (#10698)
Summary:
**Context/Summary:**
Introduce `manual_wal_flush_one_in` as titled.
- When `manual_wal_flush_one_in > 0`, we also need tracing to correctly verify recovery because WAL data can be lost in this case when `FlushWAL()` is not explicitly called by users of RocksDB (in our case, db stress) and the recovery from such potential WAL data loss is a prefix recovery that requires tracing to verify. As another consequence, we need to disable features can't run under unsync data loss with `manual_wal_flush_one_in`
Incompatibilities fixed along the way:
```
db_stress: db/db_impl/db_impl_open.cc:2063: static rocksdb::Status rocksdb::DBImpl::Open(const rocksdb::DBOptions&, const string&, const std::vector<rocksdb::ColumnFamilyDescriptor>&, std::vector<rocksdb::ColumnFamilyHandle*>*, rocksdb::DB**, bool, bool): Assertion `impl->TEST_WALBufferIsEmpty()' failed.
```
- It turns out that `Writer::AddCompressionTypeRecord` before this assertion `EmitPhysicalRecord(kSetCompressionType, encode.data(), encode.size());` but do not trigger flush if `manual_wal_flush` is set . This leads to `impl->TEST_WALBufferIsEmpty()' is false.
- As suggested, assertion is removed and violation case is handled by `FlushWAL(sync=true)` along with refactoring `TEST_WALBufferIsEmpty()` to be `WALBufferIsEmpty()` since it is used in prod code now.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10698
Test Plan:
- Locally running `python3 tools/db_crashtest.py blackbox --manual_wal_flush_one_in=1 --manual_wal_flush=1 --sync_wal_one_in=100 --atomic_flush=1 --flush_one_in=100 --column_families=3`
- Joined https://github.com/facebook/rocksdb/pull/10624 in auto CI testings with all RocksDB stress/crash test jobs
Reviewed By: ajkr
Differential Revision: D39593752
Pulled By: ajkr
fbshipit-source-id: 3a2135bb792c52d2ffa60257d4fbc557fb04d2ce
2022-09-30 22:48:33 +00:00
|
|
|
ASSERT_TRUE(options.manual_wal_flush != dbfull()->WALBufferIsEmpty());
|
2018-05-14 17:53:32 +00:00
|
|
|
ASSERT_TRUE(dbfull()->FlushWAL(false).ok());
|
Add manual_wal_flush, FlushWAL() to stress/crash test (#10698)
Summary:
**Context/Summary:**
Introduce `manual_wal_flush_one_in` as titled.
- When `manual_wal_flush_one_in > 0`, we also need tracing to correctly verify recovery because WAL data can be lost in this case when `FlushWAL()` is not explicitly called by users of RocksDB (in our case, db stress) and the recovery from such potential WAL data loss is a prefix recovery that requires tracing to verify. As another consequence, we need to disable features can't run under unsync data loss with `manual_wal_flush_one_in`
Incompatibilities fixed along the way:
```
db_stress: db/db_impl/db_impl_open.cc:2063: static rocksdb::Status rocksdb::DBImpl::Open(const rocksdb::DBOptions&, const string&, const std::vector<rocksdb::ColumnFamilyDescriptor>&, std::vector<rocksdb::ColumnFamilyHandle*>*, rocksdb::DB**, bool, bool): Assertion `impl->TEST_WALBufferIsEmpty()' failed.
```
- It turns out that `Writer::AddCompressionTypeRecord` before this assertion `EmitPhysicalRecord(kSetCompressionType, encode.data(), encode.size());` but do not trigger flush if `manual_wal_flush` is set . This leads to `impl->TEST_WALBufferIsEmpty()' is false.
- As suggested, assertion is removed and violation case is handled by `FlushWAL(sync=true)` along with refactoring `TEST_WALBufferIsEmpty()` to be `WALBufferIsEmpty()` since it is used in prod code now.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10698
Test Plan:
- Locally running `python3 tools/db_crashtest.py blackbox --manual_wal_flush_one_in=1 --manual_wal_flush=1 --sync_wal_one_in=100 --atomic_flush=1 --flush_one_in=100 --column_families=3`
- Joined https://github.com/facebook/rocksdb/pull/10624 in auto CI testings with all RocksDB stress/crash test jobs
Reviewed By: ajkr
Differential Revision: D39593752
Pulled By: ajkr
fbshipit-source-id: 3a2135bb792c52d2ffa60257d4fbc557fb04d2ce
2022-09-30 22:48:33 +00:00
|
|
|
ASSERT_TRUE(dbfull()->WALBufferIsEmpty());
|
2018-05-14 17:53:32 +00:00
|
|
|
// try the 2nd wal created during SwitchWAL
|
2020-12-10 05:19:55 +00:00
|
|
|
ASSERT_OK(dbfull()->TEST_SwitchWAL());
|
2022-05-06 20:03:58 +00:00
|
|
|
ASSERT_TRUE(Put("key" + std::to_string(0), "value").ok());
|
Add manual_wal_flush, FlushWAL() to stress/crash test (#10698)
Summary:
**Context/Summary:**
Introduce `manual_wal_flush_one_in` as titled.
- When `manual_wal_flush_one_in > 0`, we also need tracing to correctly verify recovery because WAL data can be lost in this case when `FlushWAL()` is not explicitly called by users of RocksDB (in our case, db stress) and the recovery from such potential WAL data loss is a prefix recovery that requires tracing to verify. As another consequence, we need to disable features can't run under unsync data loss with `manual_wal_flush_one_in`
Incompatibilities fixed along the way:
```
db_stress: db/db_impl/db_impl_open.cc:2063: static rocksdb::Status rocksdb::DBImpl::Open(const rocksdb::DBOptions&, const string&, const std::vector<rocksdb::ColumnFamilyDescriptor>&, std::vector<rocksdb::ColumnFamilyHandle*>*, rocksdb::DB**, bool, bool): Assertion `impl->TEST_WALBufferIsEmpty()' failed.
```
- It turns out that `Writer::AddCompressionTypeRecord` before this assertion `EmitPhysicalRecord(kSetCompressionType, encode.data(), encode.size());` but do not trigger flush if `manual_wal_flush` is set . This leads to `impl->TEST_WALBufferIsEmpty()' is false.
- As suggested, assertion is removed and violation case is handled by `FlushWAL(sync=true)` along with refactoring `TEST_WALBufferIsEmpty()` to be `WALBufferIsEmpty()` since it is used in prod code now.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10698
Test Plan:
- Locally running `python3 tools/db_crashtest.py blackbox --manual_wal_flush_one_in=1 --manual_wal_flush=1 --sync_wal_one_in=100 --atomic_flush=1 --flush_one_in=100 --column_families=3`
- Joined https://github.com/facebook/rocksdb/pull/10624 in auto CI testings with all RocksDB stress/crash test jobs
Reviewed By: ajkr
Differential Revision: D39593752
Pulled By: ajkr
fbshipit-source-id: 3a2135bb792c52d2ffa60257d4fbc557fb04d2ce
2022-09-30 22:48:33 +00:00
|
|
|
ASSERT_TRUE(options.manual_wal_flush != dbfull()->WALBufferIsEmpty());
|
2018-05-14 17:53:32 +00:00
|
|
|
ASSERT_TRUE(dbfull()->FlushWAL(false).ok());
|
Add manual_wal_flush, FlushWAL() to stress/crash test (#10698)
Summary:
**Context/Summary:**
Introduce `manual_wal_flush_one_in` as titled.
- When `manual_wal_flush_one_in > 0`, we also need tracing to correctly verify recovery because WAL data can be lost in this case when `FlushWAL()` is not explicitly called by users of RocksDB (in our case, db stress) and the recovery from such potential WAL data loss is a prefix recovery that requires tracing to verify. As another consequence, we need to disable features can't run under unsync data loss with `manual_wal_flush_one_in`
Incompatibilities fixed along the way:
```
db_stress: db/db_impl/db_impl_open.cc:2063: static rocksdb::Status rocksdb::DBImpl::Open(const rocksdb::DBOptions&, const string&, const std::vector<rocksdb::ColumnFamilyDescriptor>&, std::vector<rocksdb::ColumnFamilyHandle*>*, rocksdb::DB**, bool, bool): Assertion `impl->TEST_WALBufferIsEmpty()' failed.
```
- It turns out that `Writer::AddCompressionTypeRecord` before this assertion `EmitPhysicalRecord(kSetCompressionType, encode.data(), encode.size());` but do not trigger flush if `manual_wal_flush` is set . This leads to `impl->TEST_WALBufferIsEmpty()' is false.
- As suggested, assertion is removed and violation case is handled by `FlushWAL(sync=true)` along with refactoring `TEST_WALBufferIsEmpty()` to be `WALBufferIsEmpty()` since it is used in prod code now.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/10698
Test Plan:
- Locally running `python3 tools/db_crashtest.py blackbox --manual_wal_flush_one_in=1 --manual_wal_flush=1 --sync_wal_one_in=100 --atomic_flush=1 --flush_one_in=100 --column_families=3`
- Joined https://github.com/facebook/rocksdb/pull/10624 in auto CI testings with all RocksDB stress/crash test jobs
Reviewed By: ajkr
Differential Revision: D39593752
Pulled By: ajkr
fbshipit-source-id: 3a2135bb792c52d2ffa60257d4fbc557fb04d2ce
2022-09-30 22:48:33 +00:00
|
|
|
ASSERT_TRUE(dbfull()->WALBufferIsEmpty());
|
2018-05-14 17:53:32 +00:00
|
|
|
}
|
|
|
|
|
2022-06-17 23:45:28 +00:00
|
|
|
TEST_P(DBWriteTest, UnflushedPutRaceWithTrackedWalSync) {
|
|
|
|
// Repro race condition bug where unflushed WAL data extended the synced size
|
|
|
|
// recorded to MANIFEST despite being unrecoverable.
|
|
|
|
Options options = GetOptions();
|
|
|
|
std::unique_ptr<FaultInjectionTestEnv> fault_env(
|
|
|
|
new FaultInjectionTestEnv(env_));
|
|
|
|
options.env = fault_env.get();
|
|
|
|
options.manual_wal_flush = true;
|
|
|
|
options.track_and_verify_wals_in_manifest = true;
|
|
|
|
Reopen(options);
|
|
|
|
|
|
|
|
ASSERT_OK(Put("key1", "val1"));
|
|
|
|
|
|
|
|
SyncPoint::GetInstance()->SetCallBack(
|
|
|
|
"DBImpl::SyncWAL:Begin",
|
|
|
|
[this](void* /* arg */) { ASSERT_OK(Put("key2", "val2")); });
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->EnableProcessing();
|
|
|
|
|
|
|
|
ASSERT_OK(db_->FlushWAL(true /* sync */));
|
|
|
|
|
|
|
|
// Ensure callback ran.
|
|
|
|
ASSERT_EQ("val2", Get("key2"));
|
|
|
|
|
|
|
|
Close();
|
|
|
|
|
|
|
|
// Simulate full loss of unsynced data. This drops "key2" -> "val2" from the
|
|
|
|
// DB WAL.
|
2023-08-09 22:46:44 +00:00
|
|
|
ASSERT_OK(fault_env->DropUnsyncedFileData());
|
2022-06-17 23:45:28 +00:00
|
|
|
|
|
|
|
Reopen(options);
|
|
|
|
|
|
|
|
// Need to close before `fault_env` goes out of scope.
|
|
|
|
Close();
|
|
|
|
}
|
|
|
|
|
2022-08-25 19:53:46 +00:00
|
|
|
TEST_P(DBWriteTest, InactiveWalFullySyncedBeforeUntracked) {
|
|
|
|
// Repro bug where a WAL is appended and switched after
|
|
|
|
// `FlushWAL(true /* sync */)`'s sync finishes and before it untracks fully
|
|
|
|
// synced inactive logs. Previously such a WAL would be wrongly untracked
|
|
|
|
// so the final append would never be synced.
|
|
|
|
Options options = GetOptions();
|
|
|
|
std::unique_ptr<FaultInjectionTestEnv> fault_env(
|
|
|
|
new FaultInjectionTestEnv(env_));
|
|
|
|
options.env = fault_env.get();
|
|
|
|
Reopen(options);
|
|
|
|
|
|
|
|
ASSERT_OK(Put("key1", "val1"));
|
|
|
|
|
|
|
|
SyncPoint::GetInstance()->SetCallBack(
|
|
|
|
"DBImpl::SyncWAL:BeforeMarkLogsSynced:1", [this](void* /* arg */) {
|
|
|
|
ASSERT_OK(Put("key2", "val2"));
|
|
|
|
ASSERT_OK(dbfull()->TEST_SwitchMemtable());
|
|
|
|
});
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->EnableProcessing();
|
|
|
|
|
|
|
|
ASSERT_OK(db_->FlushWAL(true /* sync */));
|
|
|
|
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->DisableProcessing();
|
|
|
|
ROCKSDB_NAMESPACE::SyncPoint::GetInstance()->ClearAllCallBacks();
|
|
|
|
|
|
|
|
ASSERT_OK(Put("key3", "val3"));
|
|
|
|
|
|
|
|
ASSERT_OK(db_->FlushWAL(true /* sync */));
|
|
|
|
|
|
|
|
Close();
|
|
|
|
|
|
|
|
// Simulate full loss of unsynced data. This should drop nothing since we did
|
|
|
|
// `FlushWAL(true /* sync */)` before `Close()`.
|
2023-08-09 22:46:44 +00:00
|
|
|
ASSERT_OK(fault_env->DropUnsyncedFileData());
|
2022-08-25 19:53:46 +00:00
|
|
|
|
|
|
|
Reopen(options);
|
|
|
|
|
|
|
|
ASSERT_EQ("val1", Get("key1"));
|
|
|
|
ASSERT_EQ("val2", Get("key2"));
|
|
|
|
ASSERT_EQ("val3", Get("key3"));
|
|
|
|
|
|
|
|
// Need to close before `fault_env` goes out of scope.
|
|
|
|
Close();
|
|
|
|
}
|
|
|
|
|
2018-03-22 22:56:52 +00:00
|
|
|
TEST_P(DBWriteTest, IOErrorOnWALWriteTriggersReadOnlyMode) {
|
|
|
|
std::unique_ptr<FaultInjectionTestEnv> mock_env(
|
Fix many tests to run with MEM_ENV and ENCRYPTED_ENV; Introduce a MemoryFileSystem class (#7566)
Summary:
This PR does a few things:
1. The MockFileSystem class was split out from the MockEnv. This change would theoretically allow a MockFileSystem to be used by other Environments as well (if we created a means of constructing one). The MockFileSystem implements a FileSystem in its entirety and does not rely on any Wrapper implementation.
2. Make the RocksDB test suite work when MOCK_ENV=1 and ENCRYPTED_ENV=1 are set. To accomplish this, a few things were needed:
- The tests that tried to use the "wrong" environment (Env::Default() instead of env_) were updated
- The MockFileSystem was changed to support the features it was missing or mishandled (such as recursively deleting files in a directory or supporting renaming of a directory).
3. Updated the test framework to have a ROCKSDB_GTEST_SKIP macro. This can be used to flag tests that are skipped. Currently, this defaults to doing nothing (marks the test as SUCCESS) but will mark the tests as SKIPPED when RocksDB is upgraded to a version of gtest that supports this (gtest-1.10).
I have run a full "make check" with MEM_ENV, ENCRYPTED_ENV, both, and neither under both MacOS and RedHat. A few tests were disabled/skipped for the MEM/ENCRYPTED cases. The error_handler_fs_test fails/hangs for MEM_ENV (presumably a timing problem) and I will introduce another PR/issue to track that problem. (I will also push a change to disable those tests soon). There is one more test in DBTest2 that also fails which I need to investigate or skip before this PR is merged.
Theoretically, this PR should also allow the test suite to run against an Env loaded from the registry, though I do not have one to try it with currently.
Finally, once this is accepted, it would be nice if there was a CircleCI job to run these tests on a checkin so this effort does not become stale. I do not know how to do that, so if someone could write that job, it would be appreciated :)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7566
Reviewed By: zhichao-cao
Differential Revision: D24408980
Pulled By: jay-zhuang
fbshipit-source-id: 911b1554a4d0da06fd51feca0c090a4abdcb4a5f
2020-10-27 17:31:34 +00:00
|
|
|
new FaultInjectionTestEnv(env_));
|
2018-03-22 22:56:52 +00:00
|
|
|
Options options = GetOptions();
|
|
|
|
options.env = mock_env.get();
|
|
|
|
Reopen(options);
|
|
|
|
for (int i = 0; i < 2; i++) {
|
|
|
|
// Forcibly fail WAL write for the first Put only. Subsequent Puts should
|
|
|
|
// fail due to read-only mode
|
|
|
|
mock_env->SetFilesystemActive(i != 0);
|
2022-05-06 20:03:58 +00:00
|
|
|
auto res = Put("key" + std::to_string(i), "value");
|
2018-05-15 03:56:44 +00:00
|
|
|
// TSAN reports a false alarm for lock-order-inversion but Open and
|
|
|
|
// FlushWAL are not run concurrently. Disabling this until TSAN is
|
|
|
|
// fixed.
|
|
|
|
/*
|
2018-05-14 17:53:32 +00:00
|
|
|
if (options.manual_wal_flush && i == 0) {
|
|
|
|
// even with manual_wal_flush the 2nd Put should return error because of
|
|
|
|
// the read-only mode
|
|
|
|
ASSERT_TRUE(res.ok());
|
|
|
|
// we should see fs error when we do the flush
|
|
|
|
res = dbfull()->FlushWAL(false);
|
|
|
|
}
|
2018-05-15 03:56:44 +00:00
|
|
|
*/
|
|
|
|
if (!options.manual_wal_flush) {
|
2020-12-22 23:08:17 +00:00
|
|
|
ASSERT_NOK(res);
|
|
|
|
} else {
|
|
|
|
ASSERT_OK(res);
|
2018-05-15 03:56:44 +00:00
|
|
|
}
|
2018-03-22 22:56:52 +00:00
|
|
|
}
|
|
|
|
// Close before mock_env destruct.
|
|
|
|
Close();
|
|
|
|
}
|
|
|
|
|
2019-03-15 22:15:01 +00:00
|
|
|
TEST_P(DBWriteTest, IOErrorOnSwitchMemtable) {
|
|
|
|
Random rnd(301);
|
|
|
|
std::unique_ptr<FaultInjectionTestEnv> mock_env(
|
Fix many tests to run with MEM_ENV and ENCRYPTED_ENV; Introduce a MemoryFileSystem class (#7566)
Summary:
This PR does a few things:
1. The MockFileSystem class was split out from the MockEnv. This change would theoretically allow a MockFileSystem to be used by other Environments as well (if we created a means of constructing one). The MockFileSystem implements a FileSystem in its entirety and does not rely on any Wrapper implementation.
2. Make the RocksDB test suite work when MOCK_ENV=1 and ENCRYPTED_ENV=1 are set. To accomplish this, a few things were needed:
- The tests that tried to use the "wrong" environment (Env::Default() instead of env_) were updated
- The MockFileSystem was changed to support the features it was missing or mishandled (such as recursively deleting files in a directory or supporting renaming of a directory).
3. Updated the test framework to have a ROCKSDB_GTEST_SKIP macro. This can be used to flag tests that are skipped. Currently, this defaults to doing nothing (marks the test as SUCCESS) but will mark the tests as SKIPPED when RocksDB is upgraded to a version of gtest that supports this (gtest-1.10).
I have run a full "make check" with MEM_ENV, ENCRYPTED_ENV, both, and neither under both MacOS and RedHat. A few tests were disabled/skipped for the MEM/ENCRYPTED cases. The error_handler_fs_test fails/hangs for MEM_ENV (presumably a timing problem) and I will introduce another PR/issue to track that problem. (I will also push a change to disable those tests soon). There is one more test in DBTest2 that also fails which I need to investigate or skip before this PR is merged.
Theoretically, this PR should also allow the test suite to run against an Env loaded from the registry, though I do not have one to try it with currently.
Finally, once this is accepted, it would be nice if there was a CircleCI job to run these tests on a checkin so this effort does not become stale. I do not know how to do that, so if someone could write that job, it would be appreciated :)
Pull Request resolved: https://github.com/facebook/rocksdb/pull/7566
Reviewed By: zhichao-cao
Differential Revision: D24408980
Pulled By: jay-zhuang
fbshipit-source-id: 911b1554a4d0da06fd51feca0c090a4abdcb4a5f
2020-10-27 17:31:34 +00:00
|
|
|
new FaultInjectionTestEnv(env_));
|
2019-03-15 22:15:01 +00:00
|
|
|
Options options = GetOptions();
|
|
|
|
options.env = mock_env.get();
|
|
|
|
options.writable_file_max_buffer_size = 4 * 1024 * 1024;
|
|
|
|
options.write_buffer_size = 3 * 512 * 1024;
|
|
|
|
options.wal_bytes_per_sync = 256 * 1024;
|
|
|
|
options.manual_wal_flush = true;
|
|
|
|
Reopen(options);
|
|
|
|
mock_env->SetFilesystemActive(false, Status::IOError("Not active"));
|
|
|
|
Status s;
|
|
|
|
for (int i = 0; i < 4 * 512; ++i) {
|
2020-07-09 21:33:42 +00:00
|
|
|
s = Put(Key(i), rnd.RandomString(1024));
|
2019-03-15 22:15:01 +00:00
|
|
|
if (!s.ok()) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
ASSERT_EQ(s.severity(), Status::Severity::kFatalError);
|
|
|
|
|
|
|
|
mock_env->SetFilesystemActive(true);
|
|
|
|
// Close before mock_env destruct.
|
|
|
|
Close();
|
|
|
|
}
|
|
|
|
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
// Test that db->LockWAL() flushes the WAL after locking, which can fail
|
|
|
|
TEST_P(DBWriteTest, LockWALInEffect) {
|
2023-03-05 16:21:16 +00:00
|
|
|
if (mem_env_ || encrypted_env_) {
|
|
|
|
ROCKSDB_GTEST_SKIP("Test requires non-mem or non-encrypted environment");
|
|
|
|
return;
|
|
|
|
}
|
2019-04-06 13:36:42 +00:00
|
|
|
Options options = GetOptions();
|
2023-03-05 16:21:16 +00:00
|
|
|
std::shared_ptr<FaultInjectionTestFS> fault_fs(
|
|
|
|
new FaultInjectionTestFS(FileSystem::Default()));
|
|
|
|
std::unique_ptr<Env> fault_fs_env(NewCompositeEnv(fault_fs));
|
|
|
|
options.env = fault_fs_env.get();
|
2023-02-09 17:21:55 +00:00
|
|
|
options.disable_auto_compactions = true;
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
options.paranoid_checks = false;
|
2023-03-13 21:19:59 +00:00
|
|
|
options.max_bgerror_resume_count = 0; // manual Resume()
|
2019-04-06 13:36:42 +00:00
|
|
|
Reopen(options);
|
|
|
|
// try the 1st WAL created during open
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
ASSERT_OK(Put("key0", "value"));
|
|
|
|
ASSERT_NE(options.manual_wal_flush, dbfull()->WALBufferIsEmpty());
|
2024-05-21 17:17:34 +00:00
|
|
|
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
ASSERT_OK(db_->LockWAL());
|
2024-05-21 17:17:34 +00:00
|
|
|
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
ASSERT_TRUE(dbfull()->WALBufferIsEmpty());
|
2024-05-21 17:17:34 +00:00
|
|
|
uint64_t wal_num = dbfull()->TEST_GetCurrentLogNumber();
|
|
|
|
// Manual flush with wait=false should abruptly fail with TryAgain
|
|
|
|
FlushOptions flush_opts;
|
|
|
|
flush_opts.wait = false;
|
|
|
|
for (bool allow_write_stall : {true, false}) {
|
|
|
|
flush_opts.allow_write_stall = allow_write_stall;
|
|
|
|
ASSERT_TRUE(db_->Flush(flush_opts).IsTryAgain());
|
|
|
|
}
|
|
|
|
ASSERT_EQ(wal_num, dbfull()->TEST_GetCurrentLogNumber());
|
|
|
|
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
ASSERT_OK(db_->UnlockWAL());
|
2024-05-21 17:17:34 +00:00
|
|
|
|
|
|
|
// try the 2nd wal created during SwitchWAL (not locked this time)
|
2020-12-10 05:19:55 +00:00
|
|
|
ASSERT_OK(dbfull()->TEST_SwitchWAL());
|
2024-05-21 17:17:34 +00:00
|
|
|
ASSERT_NE(wal_num, dbfull()->TEST_GetCurrentLogNumber());
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
ASSERT_OK(Put("key1", "value"));
|
|
|
|
ASSERT_NE(options.manual_wal_flush, dbfull()->WALBufferIsEmpty());
|
|
|
|
ASSERT_OK(db_->LockWAL());
|
|
|
|
ASSERT_TRUE(dbfull()->WALBufferIsEmpty());
|
|
|
|
ASSERT_OK(db_->UnlockWAL());
|
|
|
|
|
Deflake DBWriteTest.LockWALInEffect (#11382)
Summary:
This test exhibited the following flaky failure:
```
db/db_write_test.cc:653: Failure
db_->Resume()
Corruption: Not active
```
I was able to repro it by applying the following patch to coerce a specific race condition:
```
diff --git a/db/db_write_test.cc b/db/db_write_test.cc
index d82c57376..775ba3cde 100644
--- a/db/db_write_test.cc
+++ b/db/db_write_test.cc
@@ -636,6 +636,10 @@ TEST_P(DBWriteTest, LockWALInEffect) {
ASSERT_TRUE(dbfull()->WALBufferIsEmpty());
ASSERT_OK(db_->UnlockWAL());
+ // Test thread: sleep interval: [0, 3)
+ // In this interval, the file system is active
+ sleep(3);
+
// Fail the WAL flush if applicable
fault_fs->SetFilesystemActive(false);
Status s = Put("key2", "value");
@@ -649,6 +653,11 @@ TEST_P(DBWriteTest, LockWALInEffect) {
ASSERT_OK(db_->LockWAL());
ASSERT_OK(db_->UnlockWAL());
}
+
+ // Test thread: sleep interval: [3, 6)
+ // In this interval, the file system is inactive
+ sleep(3);
+
fault_fs->SetFilesystemActive(true);
ASSERT_OK(db_->Resume());
// Writes should work again
diff --git a/db/flush_job.cc b/db/flush_job.cc
index 8193f594f..602ee2c9f 100644
--- a/db/flush_job.cc
+++ b/db/flush_job.cc
@@ -979,6 +979,10 @@ Status FlushJob::WriteLevel0Table() {
DirFsyncOptions(DirFsyncOptions::FsyncReason::kNewFileSynced));
}
TEST_SYNC_POINT_CALLBACK("FlushJob::WriteLevel0Table", &mems_);
+ // Flush thread: sleep interval: [0, 4)
+ // Upon awakening, the file system will be inactive. Then the MANIFEST
+ // update will fail.
+ sleep(4);
db_mutex_->Lock();
}
base_->Unref();
```
The fix for this scenario is explained in the code change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11382
Reviewed By: cbi42
Differential Revision: D45027632
Pulled By: ajkr
fbshipit-source-id: 6bfa35a5781c0c080fb74e13f2b2c9f871f7effb
2023-04-17 18:00:08 +00:00
|
|
|
// The above `TEST_SwitchWAL()` triggered a flush. That flush needs to finish
|
|
|
|
// before we make the filesystem inactive, otherwise the flush might hit an
|
|
|
|
// unrecoverable error (e.g., failed MANIFEST update).
|
|
|
|
ASSERT_OK(dbfull()->TEST_WaitForFlushMemTable(nullptr));
|
|
|
|
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
// Fail the WAL flush if applicable
|
2023-03-05 16:21:16 +00:00
|
|
|
fault_fs->SetFilesystemActive(false);
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
Status s = Put("key2", "value");
|
|
|
|
if (options.manual_wal_flush) {
|
|
|
|
ASSERT_OK(s);
|
|
|
|
// I/O failure
|
|
|
|
ASSERT_NOK(db_->LockWAL());
|
|
|
|
// Should not need UnlockWAL after LockWAL fails
|
|
|
|
} else {
|
|
|
|
ASSERT_NOK(s);
|
|
|
|
ASSERT_OK(db_->LockWAL());
|
|
|
|
ASSERT_OK(db_->UnlockWAL());
|
|
|
|
}
|
2023-03-05 16:21:16 +00:00
|
|
|
fault_fs->SetFilesystemActive(true);
|
2023-03-13 21:19:59 +00:00
|
|
|
ASSERT_OK(db_->Resume());
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
// Writes should work again
|
|
|
|
ASSERT_OK(Put("key3", "value"));
|
|
|
|
ASSERT_EQ(Get("key3"), "value");
|
|
|
|
|
|
|
|
// Should be extraneous, but allowed
|
|
|
|
ASSERT_NOK(db_->UnlockWAL());
|
|
|
|
|
|
|
|
// Close before mock_env destruct.
|
|
|
|
Close();
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_P(DBWriteTest, LockWALConcurrentRecursive) {
|
2024-05-21 17:17:34 +00:00
|
|
|
// This is a micro-stress test of LockWAL and concurrency handling.
|
|
|
|
// It is considered the most convenient way to balance functional
|
|
|
|
// coverage and reproducibility (vs. the two extremes of (a) unit tests
|
|
|
|
// tailored to specific interleavings and (b) db_stress)
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
Options options = GetOptions();
|
|
|
|
Reopen(options);
|
2024-05-21 17:17:34 +00:00
|
|
|
ASSERT_OK(Put("k1", "k1_orig"));
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
ASSERT_OK(db_->LockWAL()); // 0 -> 1
|
|
|
|
auto frozen_seqno = db_->GetLatestSequenceNumber();
|
2024-05-21 17:17:34 +00:00
|
|
|
|
|
|
|
std::string ingest_file = dbname_ + "/external.sst";
|
|
|
|
{
|
|
|
|
SstFileWriter sst_file_writer(EnvOptions(), options);
|
|
|
|
ASSERT_OK(sst_file_writer.Open(ingest_file));
|
|
|
|
ASSERT_OK(sst_file_writer.Put("k2", "k2_val"));
|
|
|
|
ExternalSstFileInfo external_info;
|
|
|
|
ASSERT_OK(sst_file_writer.Finish(&external_info));
|
|
|
|
}
|
|
|
|
AcqRelAtomic<bool> parallel_ingest_completed{false};
|
|
|
|
port::Thread parallel_ingest{[&]() {
|
|
|
|
IngestExternalFileOptions ingest_opts;
|
|
|
|
ingest_opts.move_files = true; // faster than copy
|
|
|
|
// Shouldn't finish until WAL unlocked
|
|
|
|
ASSERT_OK(db_->IngestExternalFile({ingest_file}, ingest_opts));
|
|
|
|
parallel_ingest_completed.Store(true);
|
|
|
|
}};
|
|
|
|
|
|
|
|
AcqRelAtomic<bool> flush_completed{false};
|
|
|
|
port::Thread parallel_flush{[&]() {
|
|
|
|
FlushOptions flush_opts;
|
|
|
|
// NB: Flush with wait=false case is tested above in LockWALInEffect
|
|
|
|
flush_opts.wait = true;
|
|
|
|
// allow_write_stall = true blocks in fewer cases
|
|
|
|
flush_opts.allow_write_stall = true;
|
|
|
|
// Shouldn't finish until WAL unlocked
|
|
|
|
ASSERT_OK(db_->Flush(flush_opts));
|
|
|
|
flush_completed.Store(true);
|
|
|
|
}};
|
|
|
|
|
|
|
|
AcqRelAtomic<bool> parallel_put_completed{false};
|
|
|
|
port::Thread parallel_put{[&]() {
|
|
|
|
// This can make certain failure scenarios more likely:
|
|
|
|
// sleep(1);
|
|
|
|
// Shouldn't finish until WAL unlocked
|
|
|
|
ASSERT_OK(Put("k1", "k1_mod"));
|
|
|
|
parallel_put_completed.Store(true);
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
}};
|
|
|
|
|
|
|
|
ASSERT_OK(db_->LockWAL()); // 1 -> 2
|
|
|
|
// Read-only ops are OK
|
2024-05-21 17:17:34 +00:00
|
|
|
ASSERT_EQ(Get("k1"), "k1_orig");
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
{
|
|
|
|
std::vector<LiveFileStorageInfo> files;
|
|
|
|
LiveFilesStorageInfoOptions lf_opts;
|
|
|
|
// A DB flush could deadlock
|
|
|
|
lf_opts.wal_size_for_flush = UINT64_MAX;
|
|
|
|
ASSERT_OK(db_->GetLiveFilesStorageInfo({lf_opts}, &files));
|
|
|
|
}
|
|
|
|
|
2024-05-21 17:17:34 +00:00
|
|
|
port::Thread parallel_lock_wal{[&]() {
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
ASSERT_OK(db_->LockWAL()); // 2 -> 3 or 1 -> 2
|
|
|
|
}};
|
|
|
|
|
|
|
|
ASSERT_OK(db_->UnlockWAL()); // 2 -> 1 or 3 -> 2
|
2024-05-21 17:17:34 +00:00
|
|
|
// Give parallel_put an extra chance to jump in case of bug
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
std::this_thread::yield();
|
2024-05-21 17:17:34 +00:00
|
|
|
parallel_lock_wal.join();
|
|
|
|
ASSERT_FALSE(parallel_put_completed.Load());
|
|
|
|
ASSERT_FALSE(parallel_ingest_completed.Load());
|
|
|
|
ASSERT_FALSE(flush_completed.Load());
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
|
|
|
|
// Should now have 2 outstanding LockWAL
|
2024-05-21 17:17:34 +00:00
|
|
|
ASSERT_EQ(Get("k1"), "k1_orig");
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
|
|
|
|
ASSERT_OK(db_->UnlockWAL()); // 2 -> 1
|
|
|
|
|
2024-05-21 17:17:34 +00:00
|
|
|
ASSERT_FALSE(parallel_put_completed.Load());
|
|
|
|
ASSERT_FALSE(parallel_ingest_completed.Load());
|
|
|
|
ASSERT_FALSE(flush_completed.Load());
|
|
|
|
|
|
|
|
ASSERT_EQ(Get("k1"), "k1_orig");
|
|
|
|
ASSERT_EQ(Get("k2"), "NOT_FOUND");
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
ASSERT_EQ(frozen_seqno, db_->GetLatestSequenceNumber());
|
|
|
|
|
|
|
|
// Ensure final Unlock is concurrency safe and extra Unlock is safe but
|
|
|
|
// non-OK
|
|
|
|
std::atomic<int> unlock_ok{0};
|
2024-05-21 17:17:34 +00:00
|
|
|
port::Thread parallel_stuff{[&]() {
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
if (db_->UnlockWAL().ok()) {
|
|
|
|
unlock_ok++;
|
|
|
|
}
|
|
|
|
ASSERT_OK(db_->LockWAL());
|
|
|
|
if (db_->UnlockWAL().ok()) {
|
|
|
|
unlock_ok++;
|
|
|
|
}
|
|
|
|
}};
|
|
|
|
|
|
|
|
if (db_->UnlockWAL().ok()) {
|
|
|
|
unlock_ok++;
|
|
|
|
}
|
2024-05-21 17:17:34 +00:00
|
|
|
parallel_stuff.join();
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
|
|
|
|
// There was one extra unlock, so just one non-ok
|
|
|
|
ASSERT_EQ(unlock_ok.load(), 2);
|
|
|
|
|
|
|
|
// Write can proceed
|
2024-05-21 17:17:34 +00:00
|
|
|
parallel_put.join();
|
|
|
|
ASSERT_TRUE(parallel_put_completed.Load());
|
|
|
|
ASSERT_EQ(Get("k1"), "k1_mod");
|
|
|
|
parallel_ingest.join();
|
|
|
|
ASSERT_TRUE(parallel_ingest_completed.Load());
|
|
|
|
ASSERT_EQ(Get("k2"), "k2_val");
|
|
|
|
parallel_flush.join();
|
|
|
|
ASSERT_TRUE(flush_completed.Load());
|
Cleanup, improve, stress test LockWAL() (#11143)
Summary:
The previous API comments for LockWAL didn't provide much about why you might want to use it, and didn't really meet what one would infer its contract was. Also, LockWAL was not in db_stress / crash test. In this change:
* Implement a counting semantics for LockWAL()+UnlockWAL(), so that they can safely be used concurrently across threads or recursively within a thread. This should make the API much less bug-prone and easier to use.
* Make sure no UnlockWAL() is needed after non-OK LockWAL() (to match RocksDB conventions)
* Make UnlockWAL() reliably return non-OK when there's no matching LockWAL() (for debug-ability)
* Clarify API comments on LockWAL(), UnlockWAL(), FlushWAL(), and SyncWAL(). Their exact meanings are not obvious, and I don't think it's appropriate to talk about implementation mutexes in the API comments, but about what operations might block each other.
* Add LockWAL()/UnlockWAL() to db_stress and crash test, mostly to check for assertion failures, but also checks that latest seqno doesn't change while WAL is locked. This is simpler to add when LockWAL() is allowed in multiple threads.
* Remove unnecessary use of sync points in test DBWALTest::LockWal. There was a bug during development of above changes that caused this test to fail sporadically, with and without this sync point change.
Pull Request resolved: https://github.com/facebook/rocksdb/pull/11143
Test Plan: unit tests added / updated, added to stress/crash test
Reviewed By: ajkr
Differential Revision: D42848627
Pulled By: pdillinger
fbshipit-source-id: 6d976c51791941a31fd8fbf28b0f82e888d9f4b4
2023-01-31 06:52:30 +00:00
|
|
|
// And new writes
|
2024-05-21 17:17:34 +00:00
|
|
|
ASSERT_OK(Put("k3", "val"));
|
|
|
|
ASSERT_EQ(Get("k3"), "val");
|
2019-04-06 13:36:42 +00:00
|
|
|
}
|
|
|
|
|
2020-01-17 23:53:04 +00:00
|
|
|
TEST_P(DBWriteTest, ConcurrentlyDisabledWAL) {
|
2022-11-02 21:34:24 +00:00
|
|
|
Options options = GetOptions();
|
|
|
|
options.statistics = ROCKSDB_NAMESPACE::CreateDBStatistics();
|
|
|
|
options.statistics->set_stats_level(StatsLevel::kAll);
|
|
|
|
Reopen(options);
|
|
|
|
std::string wal_key_prefix = "WAL_KEY_";
|
|
|
|
std::string no_wal_key_prefix = "K_";
|
|
|
|
// 100 KB value each for NO-WAL operation
|
|
|
|
std::string no_wal_value(1024 * 100, 'X');
|
|
|
|
// 1B value each for WAL operation
|
|
|
|
std::string wal_value = "0";
|
|
|
|
std::thread threads[10];
|
|
|
|
for (int t = 0; t < 10; t++) {
|
|
|
|
threads[t] = std::thread([t, wal_key_prefix, wal_value, no_wal_key_prefix,
|
2024-04-25 21:34:11 +00:00
|
|
|
no_wal_value, &options, this] {
|
2022-11-02 21:34:24 +00:00
|
|
|
for (int i = 0; i < 10; i++) {
|
|
|
|
ROCKSDB_NAMESPACE::WriteOptions write_option_disable;
|
|
|
|
write_option_disable.disableWAL = true;
|
|
|
|
ROCKSDB_NAMESPACE::WriteOptions write_option_default;
|
|
|
|
std::string no_wal_key =
|
|
|
|
no_wal_key_prefix + std::to_string(t) + "_" + std::to_string(i);
|
|
|
|
ASSERT_OK(this->Put(no_wal_key, no_wal_value, write_option_disable));
|
|
|
|
std::string wal_key =
|
|
|
|
wal_key_prefix + std::to_string(i) + "_" + std::to_string(i);
|
|
|
|
ASSERT_OK(this->Put(wal_key, wal_value, write_option_default));
|
2024-04-25 21:34:11 +00:00
|
|
|
ASSERT_OK(dbfull()->SyncWAL())
|
|
|
|
<< "options.env: " << options.env << ", env_: " << env_
|
|
|
|
<< ", env_->is_wal_sync_thread_safe_: "
|
|
|
|
<< env_->is_wal_sync_thread_safe_.load();
|
2022-11-02 21:34:24 +00:00
|
|
|
}
|
|
|
|
return;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
for (auto& t : threads) {
|
|
|
|
t.join();
|
|
|
|
}
|
|
|
|
uint64_t bytes_num = options.statistics->getTickerCount(
|
|
|
|
ROCKSDB_NAMESPACE::Tickers::WAL_FILE_BYTES);
|
|
|
|
// written WAL size should less than 100KB (even included HEADER & FOOTER
|
|
|
|
// overhead)
|
|
|
|
ASSERT_LE(bytes_num, 1024 * 100);
|
2020-01-17 23:53:04 +00:00
|
|
|
}
|
|
|
|
|
2024-03-21 19:29:35 +00:00
|
|
|
void CorruptLogFile(Env* env, Options& options, std::string log_path,
|
|
|
|
uint64_t log_num, int record_num) {
|
|
|
|
std::shared_ptr<FileSystem> fs = env->GetFileSystem();
|
|
|
|
std::unique_ptr<SequentialFileReader> file_reader;
|
|
|
|
Status status;
|
|
|
|
{
|
|
|
|
std::unique_ptr<FSSequentialFile> file;
|
|
|
|
status = fs->NewSequentialFile(log_path, FileOptions(), &file, nullptr);
|
|
|
|
ASSERT_EQ(status, IOStatus::OK());
|
|
|
|
file_reader.reset(new SequentialFileReader(std::move(file), log_path));
|
|
|
|
}
|
|
|
|
std::unique_ptr<log::Reader> reader(new log::Reader(
|
|
|
|
nullptr, std::move(file_reader), nullptr, false, log_num));
|
|
|
|
std::string scratch;
|
|
|
|
Slice record;
|
|
|
|
uint64_t record_checksum;
|
|
|
|
for (int i = 0; i < record_num; ++i) {
|
|
|
|
ASSERT_TRUE(reader->ReadRecord(&record, &scratch, options.wal_recovery_mode,
|
|
|
|
&record_checksum));
|
|
|
|
}
|
|
|
|
uint64_t rec_start = reader->LastRecordOffset();
|
|
|
|
reader.reset();
|
|
|
|
{
|
|
|
|
std::unique_ptr<FSRandomRWFile> file;
|
|
|
|
status = fs->NewRandomRWFile(log_path, FileOptions(), &file, nullptr);
|
|
|
|
ASSERT_EQ(status, IOStatus::OK());
|
|
|
|
uint32_t bad_lognum = 0xff;
|
|
|
|
ASSERT_EQ(file->Write(
|
|
|
|
rec_start + 7,
|
|
|
|
Slice(reinterpret_cast<char*>(&bad_lognum), sizeof(uint32_t)),
|
|
|
|
IOOptions(), nullptr),
|
|
|
|
IOStatus::OK());
|
|
|
|
ASSERT_OK(file->Close(IOOptions(), nullptr));
|
|
|
|
file.reset();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_P(DBWriteTest, RecycleLogTest) {
|
|
|
|
Options options = GetOptions();
|
|
|
|
options.recycle_log_file_num = 0;
|
|
|
|
options.avoid_flush_during_recovery = true;
|
|
|
|
options.wal_recovery_mode = WALRecoveryMode::kPointInTimeRecovery;
|
|
|
|
|
|
|
|
Reopen(options);
|
|
|
|
ASSERT_OK(Put(Key(1), "val1"));
|
|
|
|
ASSERT_OK(Put(Key(2), "val1"));
|
|
|
|
|
|
|
|
uint64_t latest_log_num = 0;
|
|
|
|
std::unique_ptr<LogFile> log_file;
|
|
|
|
ASSERT_OK(dbfull()->GetCurrentWalFile(&log_file));
|
|
|
|
latest_log_num = log_file->LogNumber();
|
|
|
|
Reopen(options);
|
|
|
|
ASSERT_OK(Put(Key(3), "val3"));
|
|
|
|
|
|
|
|
// Corrupt second entry of first log
|
|
|
|
std::string log_path = LogFileName(dbname_, latest_log_num);
|
|
|
|
CorruptLogFile(env_, options, log_path, latest_log_num, 2);
|
|
|
|
|
|
|
|
Reopen(options);
|
|
|
|
ASSERT_EQ(Get(Key(1)), "val1");
|
|
|
|
ASSERT_EQ(Get(Key(2)), "NOT_FOUND");
|
|
|
|
ASSERT_EQ(Get(Key(3)), "NOT_FOUND");
|
|
|
|
}
|
|
|
|
|
|
|
|
TEST_P(DBWriteTest, RecycleLogTestCFAheadOfWAL) {
|
|
|
|
Options options = GetOptions();
|
|
|
|
options.recycle_log_file_num = 0;
|
|
|
|
options.avoid_flush_during_recovery = true;
|
|
|
|
options.wal_recovery_mode = WALRecoveryMode::kPointInTimeRecovery;
|
|
|
|
|
|
|
|
CreateAndReopenWithCF({"pikachu"}, options);
|
|
|
|
ASSERT_OK(Put(1, Key(1), "val1"));
|
|
|
|
ASSERT_OK(Put(0, Key(2), "val2"));
|
|
|
|
|
|
|
|
uint64_t latest_log_num = 0;
|
|
|
|
std::unique_ptr<LogFile> log_file;
|
|
|
|
ASSERT_OK(dbfull()->GetCurrentWalFile(&log_file));
|
|
|
|
latest_log_num = log_file->LogNumber();
|
|
|
|
ASSERT_OK(Flush(1));
|
|
|
|
ASSERT_OK(Put(1, Key(3), "val3"));
|
|
|
|
|
|
|
|
// Corrupt second entry of first log
|
|
|
|
std::string log_path = LogFileName(dbname_, latest_log_num);
|
|
|
|
CorruptLogFile(env_, options, log_path, latest_log_num, 2);
|
|
|
|
|
|
|
|
ASSERT_EQ(TryReopenWithColumnFamilies({"default", "pikachu"}, options),
|
|
|
|
Status::Corruption());
|
|
|
|
}
|
|
|
|
|
2024-04-29 19:25:00 +00:00
|
|
|
TEST_P(DBWriteTest, RecycleLogToggleTest) {
|
|
|
|
Options options = GetOptions();
|
|
|
|
options.recycle_log_file_num = 0;
|
|
|
|
options.avoid_flush_during_recovery = true;
|
|
|
|
options.wal_recovery_mode = WALRecoveryMode::kPointInTimeRecovery;
|
|
|
|
|
|
|
|
Destroy(options);
|
|
|
|
Reopen(options);
|
|
|
|
// After opening, a new log gets created, say 1.log
|
|
|
|
ASSERT_OK(Put(Key(1), "val1"));
|
|
|
|
|
|
|
|
options.recycle_log_file_num = 1;
|
|
|
|
Reopen(options);
|
|
|
|
// 1.log is added to alive_log_files_
|
|
|
|
ASSERT_OK(Put(Key(2), "val1"));
|
|
|
|
ASSERT_OK(Flush());
|
|
|
|
// 1.log should be deleted and not recycled, since it
|
|
|
|
// was created by the previous Reopen
|
|
|
|
ASSERT_OK(Put(Key(1), "val2"));
|
|
|
|
ASSERT_OK(Flush());
|
|
|
|
|
|
|
|
options.recycle_log_file_num = 1;
|
|
|
|
Reopen(options);
|
|
|
|
ASSERT_EQ(Get(Key(1)), "val2");
|
|
|
|
}
|
|
|
|
|
2020-06-03 22:53:09 +00:00
|
|
|
INSTANTIATE_TEST_CASE_P(DBWriteTestInstance, DBWriteTest,
|
|
|
|
testing::Values(DBTestBase::kDefault,
|
|
|
|
DBTestBase::kConcurrentWALWrites,
|
|
|
|
DBTestBase::kPipelinedWrite));
|
2017-05-31 17:45:47 +00:00
|
|
|
|
2020-02-20 20:07:53 +00:00
|
|
|
} // namespace ROCKSDB_NAMESPACE
|
2017-05-31 17:45:47 +00:00
|
|
|
|
|
|
|
int main(int argc, char** argv) {
|
2020-02-20 20:07:53 +00:00
|
|
|
ROCKSDB_NAMESPACE::port::InstallStackTraceHandler();
|
2017-05-31 17:45:47 +00:00
|
|
|
::testing::InitGoogleTest(&argc, argv);
|
2021-11-08 19:04:01 +00:00
|
|
|
RegisterCustomObjects(argc, argv);
|
2017-05-31 17:45:47 +00:00
|
|
|
return RUN_ALL_TESTS();
|
|
|
|
}
|