Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential Manifest and Log File ID Conflict During Recovery Process in LevelDB #1193

Open
owenliang opened this issue Jun 16, 2024 · 0 comments

Comments

@owenliang
Copy link

In the function Status VersionSet::Recover(bool* save_manifest), the statement manifest_file_number_ = next_file; could potentially lead to a scenario where the identifier of the manifest file matches that of the log file for the memtable. The chronological sequence of events that might give rise to this situation is outlined as follows:

Memtable Writing: The memtable is actively being written to (with the log file at ID 4 and next_file_num set to 5), while the immutable memtable (imm) is empty.

Compaction Occurs: A compaction process consolidates SST files, and within the edit log, next_file_number_ is recorded as 5.

Memtable Switch: The memtable becomes full, triggering a switch to a new log file (now at ID 5, with next_file_num advanced to 6), and the filled memtable is moved to the imm state.

Database Restart: The database undergoes a restart.

Recovery Process: During VersionSet::Recover(), the edit log with next_file_number_ as 5 is read, prompting the creation and redoing of the manifest file using the ID 5.

Overlap Identified: Consequently, both the manifest file and the log file now share the same identifier, which is 5.

While this overlap in identifiers does not impede the functional operation of the database, I seek confirmation on whether this particular sequence of events is plausible. Thank you for your attention to this matter.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant