mirror of
https://github.com/facebook/rocksdb.git
synced 2026-10-23 08:09:02 +03:00
Summary: Pull Request resolved: https://github.com/facebook/rocksdb/pull/15193 Keep `DB::Write`'s existing immediate `IOError` contract while allowing RocksDB to recover safely when a remote file system reports that a WAL handle is permanently unusable. The public API documentation makes the persisted-state boundary, reopen behavior, and safe post-resumption retry point explicit. Normal operation remains unchanged; the additional protocol is entered only after a supported file-scoped WAL error. ### Motivation A WAL write crosses an acknowledgement boundary: storage can accept the complete record and then fail before the caller receives confirmation. The resulting `IOError` therefore cannot tell RocksDB or the application whether the record is absent, partial, or complete. At the same time, the remote file handle can become permanently poisoned, so retrying that same handle can never succeed. The previous recovery path retried the poisoned handle. Simply replacing it is not sufficient: RocksDB must also prevent reuse of an ambiguous sequence range, keep every column family on one durable boundary, and prevent WAL tailers from publishing a physically complete record that successful live resumption deliberately abandoned. The new protocol quarantines the affected WALs, reserves the ambiguous sequence range, creates a replacement WAL, atomically persists acknowledged state, retires the quarantined handles, and only then resumes writes. ### Behavior changes #### 1. Recovering from a poisoned remote WAL handle - **Why required:** A remote file system can permanently poison a WAL handle after an I/O failure. Retrying that handle cannot succeed and leaves the database write-stopped. - **Previous behavior:** RocksDB retried the same WAL handle during recovery. - **New behavior:** The remote file system marks the failure as file-scoped. RocksDB creates a replacement WAL, atomically persists all state that could depend on the failed WAL, and then removes the quarantined WAL handles from active use. Physical file deletion remains part of normal cleanup. #### 2. Preserving an indeterminate WAL write outcome - **Why required:** A WAL record can reach storage before the append returns `IOError`; neither RocksDB nor the application can know the outcome from that error alone. - **Previous behavior:** Recovery could reuse a file-scoped failed write group's sequence numbers, allowing a later acknowledged write to overlap a record that might already be in the WAL. The public write API did not explain the acknowledgement ambiguity or distinguish live resumption from close/reopen recovery. - **New behavior:** `DB::Write` still returns the original `IOError` immediately and does not retry the logical batch. Normal DB reads can continue, but the failed write is not visible in that DB session. The persisted DB remains indeterminate with respect to the failed write until supported file-scoped live resumption succeeds without closing or reopening the DB. On reopen, or for any other WAL error without the durable-abandonment guarantee, applications must resolve consistency within RocksDB's documented guarantees, including `WALRecoveryMode`, through idempotency, deduplication, reconciliation, or an equivalent mechanism. After successful supported file-scoped live resumption, RocksDB has durably abandoned the failed batch and reserved its sequence range; retrying the same logical write is then recommended to preserve one linear logical history. #### 3. Keeping TransactionLogIterator consistent with live resumption - **Why required:** A physically complete error-returned record can remain readable from its WAL even though supported file-scoped recovery excludes that batch from the database. Returning it from `GetUpdatesSince()` would make replication or change-data-capture consumers diverge from the recovered DB. - **Previous behavior:** An iterator opened before recovery could return the abandoned batch. A new iterator could also return it while the physical WAL remained visible. - **New behavior:** For file-scoped failures, RocksDB records the exact sequence range and WAL number of each indeterminate write. For the lifetime of that open DB, existing and new WAL iterators stop with `Status::NotFound` before the range, whether the physical record is complete or absent. A caller can begin a new iterator after the reserved range. Iterator creation snapshots the recovery-gap generation together with its WAL-file view so a failure on a later, unseen WAL returns `TryAgain` for the old iterator instead of skipping its valid prefix. #### 4. Keeping all column families on one recovery boundary - **Why required:** A write batch can update multiple column families. Retiring its WAL after independently persisting only some column families can expose a partially applied batch after reopen. - **Previous behavior:** With `atomic_flush=false`, recovery could persist column families independently before abandoning the WAL. - **New behavior:** File-scoped WAL recovery force-flushes every live column family atomically and verifies that each one advanced beyond the failed WAL before writers are retired or writes resume. #### 5. Merging concurrent WAL failures - **Why required:** Another WAL write can fail while an earlier recovery attempt temporarily releases the DB mutex. - **Previous behavior:** A later failed WAL cutoff or ambiguous sequence could be overwritten or cleared by the earlier recovery attempt. - **New behavior:** Each error episode monotonically merges the largest failed WAL cutoff and the sequence range of the latest ambiguous write group. Recovery clears the quarantine cutoff only if no concurrent failure extended it; otherwise the newer failure remains write-stopping for the next attempt. Iterator fencing tracks the actual ambiguous write range separately, so an older failed `SyncWAL()` and a newer ambiguous write are not incorrectly paired. #### 6. Retaining file scope through `NoSpace` recovery - **Why required:** `NoSpace` can still identify one permanently unusable WAL handle. - **Previous behavior:** The `SstFileManager` recovery path entered generic recovery without carrying the failed WAL context. - **New behavior:** File-scoped `NoSpace` carries the same cutoff and sequence evidence through the `SstFileManager` path as other file-scoped WAL errors. #### 7. Scoping recovery context to one error episode - **Why required:** A completed recovery must not affect a later unrelated background error. - **Previous behavior:** WAL recovery context could remain latched after `ClearBGError` succeeded. - **New behavior:** Successful background-error clearing resets the context. A failed recovery retains it so a later retry has the same safety information. The separate iterator gap record remains for the lifetime of the open DB because later WAL readers must continue to reject the abandoned physical record. #### 8. Preserving successful `SyncWAL` metadata - **Why required:** A healthy WAL can finish syncing while a separate recovery error already exists. - **Previous behavior:** `SyncWAL` could return the existing background error before applying the successful WAL's `VersionEdit`, dropping its MANIFEST update. - **New behavior:** `SyncWAL` skips quarantined writers, applies metadata for successfully synced healthy WALs, and only then returns any existing recovery error. #### 9. Classifying only the intended remote-file-system failure - **Why required:** File-scoped recovery is valid only for an actual WAL `IOError` from a handle whose ownership is still valid. - **Previous behavior:** Poison state could be queried before ownership fencing was resolved, and file scope could be stamped onto a non-I/O status. - **New behavior:** Ownership fencing is resolved first, poison state is queried afterward, and only an actual `IOError` can be classified as file-scoped. `IOFenced` remains fatal. #### 10. Preserving `paranoid_checks=false` retry behavior - **Why required:** Non-paranoid mode historically cleared a writer's sticky error so a later operation could retry after storage recovered. - **Previous behavior:** Avoiding reclassification of a cached synthetic writer error also bypassed `WALIOStatusCheck`, so later `SyncWAL` calls kept returning the stale error. - **New behavior:** A cached error still fails the current `SyncWAL` call, but the non-paranoid path resets the writer for a later retry without setting a background error or entering file-scoped recovery. #### 11. Preserving async WAL precreation across recovery - **Why required:** A precreated WAL is an unpublished replacement and is not the active WAL. Recovery can also consume the prepared slot while background work is stopped. - **Previous behavior:** A file-scoped failure while creating or starting the unpublished replacement was attributed to the active WAL, unnecessarily quarantining it. After successful recovery consumed a prepared WAL, the next slot was not replenished, so the following rotation created its WAL synchronously. - **New behavior:** Only an active WAL `WriteBuffer()` failure attaches the active-WAL cutoff. A failed unpublished candidate is discarded while the current WAL remains active, and successful recovery schedules the next async precreation after `ClearBGError()` re-enables background work. ### Implementation - Carry `DBRecoverContext` through generic, `NoSpace`, and `SstFileManager` recovery, merging WAL cutoffs and failed write-group sequence ranges independently of error severity. Generic errors retain the range only so a later retry that establishes file scope can activate the stronger protocol; they do not persist a reservation or install an iterator gap on their own. - Document the WAL acknowledgement ambiguity, persisted-state boundary, reopen behavior, application consistency requirements, and post-resumption retry guidance on the public `DB::Write` API. - Publish a lock-free quarantine cutoff used by write and sync paths; replace even an empty failed current WAL; persist file-scoped ambiguous sequence reservations; force and verify an atomic all-column-family flush; and detach quarantined writers only after that durable boundary. - Record each file-scoped ambiguous write group's exact WAL number and sequence range in a DB-lifetime tracker shared by `WalManager` and all `WalIteratorImpl` instances. Stop an iterator before a batch that contains or crosses the range, and use a generation snapshot to preserve the existing `TryAgain` behavior when an iterator's fixed WAL-file view predates the failure. - Keep successful healthy-WAL tracking edits in `SyncWAL`, reset completed recovery context, and preserve legacy non-paranoid writer reset behavior. - Distinguish failures on an unpublished replacement WAL from failures flushing the active WAL. Log the failed replacement identity, keep the active WAL out of quarantine, and replenish the async-precreation slot after successful recovery. - Classify poisoned remote-file-system handles after ownership fencing and only for `IOError`. - Add lifecycle logging and a state-machine comment covering quarantine, sequence reservation, iterator fencing, replacement, atomic persistence, retirement, and concurrent-error handoff. - Add an opt-in `db_stress` mode that injects file-scoped faults only into WAL writes, disables WAL tracking in that mode, validates unsupported direct invocations, and sanitizes crash-test parameters to the supported recovery envelope. A small fraction of ordinary non-specialized crash-test runs select this mode automatically; existing stress behavior is unchanged when the flag is off. - Make the concurrent-error regression test hold the initial background flush until `SyncWAL` records the intended older-WAL error, preventing scheduler-dependent retirement of the test WAL before fault injection. ### Safety boundaries and unsupported cases - Automatic file-scoped WAL recovery fails closed with `NotSupported` for manual WAL flush, 2PC/transactions, two write queues, pipelined or unordered writes, WAL recycling, WAL TTL or size retention, either WAL-tracking mode, or blob direct writes. - Unsupported recovery leaves the DB write-stopped. `DB::Resume()` returns `NotSupported`; after correcting the I/O condition, operational recovery requires close and reopen. - The failed logical batch is never retried. Only supported file-scoped recovery durably reserves its sequence range and fences `GetUpdatesSince()`. Generic WAL errors retain the existing indeterminate outcome and can replay after close/reopen; applications must use idempotency or reconciliation unless successful file-scoped live resumption has provided the stronger guarantee. - Failed recovery attempts retain their context. Only a successful `ClearBGError` resets it. - Physical WAL deletion is not part of the recovery correctness boundary; normal obsolete-file cleanup removes files later. - The TransactionLogIterator ambiguity fence is kept for the lifetime of the DB instance that observed the file-scoped error and is not persisted as new MANIFEST metadata. After a later close/reopen, normal WAL recovery and obsolete-WAL retention/deletion semantics apply. - The in-memory iterator-gap tracker can grow with the number of recovered file-scoped failures during one DB lifetime. Safe pruning must account for retained WALs and existing iterator snapshots; it is left for follow-up. - Async WAL precreation remains disabled with WAL recycling. A prepared WAL is unpublished until its start records succeed; failure before installation does not make the active WAL file-scoped. - The new stress mode is test-only and defaults off, so normal `db_stress` and database operation without an error are unchanged. - Automatic stress-profile selection is limited to fully parsed, supported configurations. Explicit targeted runs reject options files and other unsupported combinations. ### Tests and known limitations - The affected recovery, WAL-manager, WAL-iterator, fault-injection, async-WAL-precreation, and secondary-close binaries build successfully. - Checked-status suites pass for all 70 `error_handler_fs_test` cases, all 7 `wal_manager_test` cases, all 11 `db_log_iter_test` cases, all 8 `fault_injection_fs_test` cases, and all 5 `DBWALTest.AsyncWalPrecreate*` cases. `DBSecondaryTest.SecondaryCloseFiles` passes 20 consecutive repetitions. - Focused regressions cover file-scoped gap fencing after an iterator snapshot, generic errors not installing a file-scoped sequence gap, and later recovery discovering that a generic error is file-scoped. - Earlier validation on this diff also passed crash-test unit coverage, remote-file-system adapter tests, repeated concurrency tests, two bounded multi-column-family stress runs, and bounded black-box crash/reopen dry runs. - The exact internal RocksDB format check and `arc f --take-formatters --enforce-lint-clean` report no formatting or lint issues. - The full crash/stress matrix and TSAN were not run. Reviewed By: pdillinger Differential Revision: D119324616 fbshipit-source-id: 05779d2bff7018f0ae69c4cbbe5b6455a45675d6
170 lines
6.1 KiB
C++
170 lines
6.1 KiB
C++
// Copyright (c) 2011-present, Facebook, Inc. All rights reserved.
|
|
// This source code is licensed under both the GPLv2 (found in the
|
|
// COPYING file in the root directory) and Apache 2.0 License
|
|
// (found in the LICENSE.Apache file in the root directory).
|
|
#pragma once
|
|
|
|
#include <map>
|
|
#include <memory>
|
|
#include <vector>
|
|
|
|
#include "db/log_reader.h"
|
|
#include "db/version_set.h"
|
|
#include "file/filename.h"
|
|
#include "logging/logging.h"
|
|
#include "options/db_options.h"
|
|
#include "port/port.h"
|
|
#include "rocksdb/env.h"
|
|
#include "rocksdb/options.h"
|
|
#include "rocksdb/types.h"
|
|
#include "rocksdb/wal_iterator.h"
|
|
|
|
namespace ROCKSDB_NAMESPACE {
|
|
|
|
// A file-scoped indeterminate WAL append can leave a complete physical record
|
|
// that is not part of the database after successful live resumption. Keep the
|
|
// end sequence of each such write group for the lifetime of the open DB so both
|
|
// existing and newly created WAL iterators stop before exposing that record.
|
|
struct WalRecoverySequenceGap {
|
|
uint64_t wal_number;
|
|
SequenceNumber start_sequence;
|
|
SequenceNumber end_sequence;
|
|
uint64_t generation;
|
|
};
|
|
|
|
class WalRecoverySequenceTracker {
|
|
public:
|
|
void Record(uint64_t wal_number, SequenceNumber start_sequence,
|
|
SequenceNumber end_sequence);
|
|
bool FirstAtOrAfter(SequenceNumber sequence,
|
|
WalRecoverySequenceGap* recovery_gap) const;
|
|
uint64_t CurrentGeneration() const;
|
|
|
|
private:
|
|
mutable port::Mutex mutex_;
|
|
// TODO: Bound DB-lifetime growth by pruning gaps only after their WALs are no
|
|
// longer retained and no existing iterator snapshot can still observe them.
|
|
// WAL purge alone is insufficient because iterators share this tracker.
|
|
std::map<SequenceNumber, WalRecoverySequenceGap> gaps_by_end_sequence_;
|
|
uint64_t generation_ = 0;
|
|
};
|
|
|
|
class WalFileImpl : public WalFile {
|
|
public:
|
|
WalFileImpl(uint64_t logNum, WalFileType logType, SequenceNumber startSeq,
|
|
uint64_t sizeBytes)
|
|
: logNumber_(logNum),
|
|
type_(logType),
|
|
startSequence_(startSeq),
|
|
sizeFileBytes_(sizeBytes) {}
|
|
|
|
std::string PathName() const override {
|
|
if (type_ == kArchivedLogFile) {
|
|
return ArchivedLogFileName("", logNumber_);
|
|
}
|
|
return LogFileName("", logNumber_);
|
|
}
|
|
|
|
uint64_t LogNumber() const override { return logNumber_; }
|
|
|
|
WalFileType Type() const override { return type_; }
|
|
|
|
SequenceNumber StartSequence() const override { return startSequence_; }
|
|
|
|
uint64_t SizeFileBytes() const override { return sizeFileBytes_; }
|
|
|
|
bool operator<(const WalFile& that) const {
|
|
return LogNumber() < that.LogNumber();
|
|
}
|
|
|
|
private:
|
|
uint64_t logNumber_;
|
|
WalFileType type_;
|
|
SequenceNumber startSequence_;
|
|
uint64_t sizeFileBytes_;
|
|
};
|
|
|
|
class WalIteratorImpl : public WalIterator {
|
|
public:
|
|
WalIteratorImpl(
|
|
const std::string& dir, const ImmutableDBOptions* options,
|
|
const WalIterator::ReadOptions& read_options, const EnvOptions& soptions,
|
|
const SequenceNumber seqNum, std::unique_ptr<VectorWalPtr> files,
|
|
VersionSet const* const versions, const bool seq_per_batch,
|
|
const std::shared_ptr<IOTracer>& io_tracer,
|
|
std::shared_ptr<WalRecoverySequenceTracker> recovery_sequence_tracker,
|
|
uint64_t recovery_sequence_generation);
|
|
|
|
bool Valid() override;
|
|
|
|
void Next() override;
|
|
|
|
Status status() override;
|
|
|
|
BatchResult GetBatch() override;
|
|
|
|
private:
|
|
const std::string& dir_;
|
|
const ImmutableDBOptions* options_;
|
|
const WalIterator::ReadOptions read_options_;
|
|
const EnvOptions& soptions_;
|
|
SequenceNumber starting_sequence_number_;
|
|
std::unique_ptr<VectorWalPtr> files_;
|
|
// Used only to get latest seq. num
|
|
// TODO(icanadi) can this be just a callback?
|
|
VersionSet const* const versions_;
|
|
std::shared_ptr<IOTracer> io_tracer_;
|
|
std::shared_ptr<WalRecoverySequenceTracker> recovery_sequence_tracker_;
|
|
uint64_t recovery_sequence_generation_;
|
|
|
|
// State variables
|
|
bool started_;
|
|
bool is_valid_; // not valid when it starts of.
|
|
// Once this is set to a non-OK status the iterator is spent: Next() is a
|
|
// no-op and the status never changes again.
|
|
Status current_status_;
|
|
size_t current_file_index_;
|
|
std::unique_ptr<WriteBatch> current_batch_;
|
|
std::unique_ptr<log::Reader> current_log_reader_;
|
|
std::string scratch_;
|
|
Status OpenLogFile(const WalFile* log_file,
|
|
std::unique_ptr<SequentialFileReader>* file);
|
|
|
|
struct LogReporter : public log::Reader::Reporter {
|
|
Env* env;
|
|
Logger* info_log;
|
|
void Corruption(size_t bytes, const Status& s,
|
|
uint64_t /*log_number*/ = kMaxSequenceNumber) override {
|
|
ROCKS_LOG_ERROR(info_log, "dropping %" ROCKSDB_PRIszt " bytes; %s", bytes,
|
|
s.ToString().c_str());
|
|
}
|
|
virtual void Info(const char* s) { ROCKS_LOG_INFO(info_log, "%s", s); }
|
|
} reporter_;
|
|
|
|
SequenceNumber
|
|
current_batch_seq_; // sequence number at start of current batch
|
|
SequenceNumber current_last_seq_; // last sequence in the current batch
|
|
// Reads from transaction log only if the writebatch record has been written
|
|
bool RestrictedRead(Slice* record);
|
|
// Seeks to starting_sequence_number_ reading from start_file_index in files_.
|
|
// If strict is set, then must get a batch starting with
|
|
// starting_sequence_number_.
|
|
void SeekToStartSequence(uint64_t start_file_index = 0, bool strict = false);
|
|
// Implementation of Next. SeekToStartSequence calls it internally with
|
|
// internal=true to let it find next entry even if it has to jump gaps because
|
|
// the iterator may start off from the first available entry but promises to
|
|
// be continuous after that
|
|
void NextImpl(bool internal = false);
|
|
// Check if batch is expected, else return false
|
|
bool IsBatchExpected(const WriteBatch* batch, SequenceNumber expected_seq);
|
|
// Update current batch if a continuous batch is found.
|
|
void UpdateCurrentWriteBatch(const Slice& record);
|
|
// End the run before a batch that contains or crosses a sequence reserved
|
|
// after an indeterminate WAL write.
|
|
bool StopBeforeRecoveryGap(uint64_t wal_number,
|
|
SequenceNumber batch_last_sequence);
|
|
Status OpenLogReader(const WalFile* file);
|
|
};
|
|
|
|
} // namespace ROCKSDB_NAMESPACE
|