[sys-4815] treat inconsistent epoch number as poison instead of corruption #284
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.