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

[sys-4815] treat inconsistent epoch number as poison instead of corruption #284

Merged
merged 1 commit into from
Sep 15, 2023

Conversation

seckcoder
Copy link

@seckcoder seckcoder commented Sep 14, 2023

The consistency check compares the replicated epoch number from leader against epoch number calculated based on existing files on followers. It's actually possible that the consistency check fails in following rare case:

D as leader running on old rocksdb, E as follower running on new rocksdb. Then D is re-opened as leader on new rocksdb, during which we recover the epoch number on db open. During recovery, the epoch number calculated on D might be different from the epoch number on E. But we won't detect the inconsistency until the mismatched files are compacted, which may only happen a few hours/days later.

This is fine since E will resync manifest files when re-opened. And very likely shard reopen has already happened during latest leaf roll. But out of precaution, let's treat this as poison so that E will reopen immediately instead of corruption (which will cause permanently errored shards) before enabling epoch replication for all orgs.

@seckcoder seckcoder merged commit 8dc6a23 into master Sep 15, 2023
0 of 2 checks passed
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

Successfully merging this pull request may close these issues.

2 participants