-
Notifications
You must be signed in to change notification settings - Fork 25.3k
Fix Snapshots Recording Incorrect Max. Segment Counts #74291
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
Conversation
If sequence numbers are equal across snapshots (and thus no files get written to the repository) the segment count in the index commit is not reliable as it may have changed due to background merges. => fixed by always using the segment count determined from the file names in the snapshot instead closes elastic#74249
Pinging @elastic/es-distributed (Team:Distributed) |
Could we set |
Done, so much cuter :) Thanks! |
final int rounds = scaledRandomIntBetween(50, 300); | ||
for (int i = 0; i < rounds; ++i) { | ||
final int numDocs = scaledRandomIntBetween(100, 1000); | ||
BulkRequestBuilder request = client().prepareBulk(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it'd be better to refresh on each bulk to force a segment to be written:
BulkRequestBuilder request = client().prepareBulk(); | |
BulkRequestBuilder request = client().prepareBulk().setRefreshPolicy(WriteRequest.RefreshPolicy.IMMEDIATE); |
I suspect if we did that we wouldn't need so many rounds.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ right done in d629c74
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
.prepareUpdateSettings(indexName) | ||
.setSettings( | ||
Settings.builder() | ||
.put(MergePolicyConfig.INDEX_MERGE_POLICY_SEGMENTS_PER_TIER_SETTING.getKey(), "2") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 we know we did ≥3 rounds, each of which made ≥1 segment, and they're all pretty small (≤2MB) so this guarantees a merge IIUC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
++ that was assumption here. Also ran a few hundred rounds of this to verify and it seems to hold 🤞
Thanks David! |
If sequence numbers are equal across snapshots (and thus no files get written to the repository) the segment count in the index commit is not reliable as it may have changed due to background merges. => fixed by always using the segment count determined from the file names in the snapshot instead closes elastic#74249
If sequence numbers are equal across snapshots (and thus no files get written to the repository) the segment count in the index commit is not reliable as it may have changed due to background merges. => fixed by always using the segment count determined from the file names in the snapshot instead closes elastic#74249
If sequence numbers are equal across snapshots (and thus no files get written to the repository) the segment count in the index commit is not reliable as it may have changed due to background merges. => fixed by always using the segment count determined from the file names in the snapshot instead closes #74249
If sequence numbers are equal across snapshots (and thus no files get written to the repository) the segment count in the index commit is not reliable as it may have changed due to background merges. => fixed by always using the segment count determined from the file names in the snapshot instead closes #74249
If sequence numbers are equal across snapshots (and thus no files get written to the repository)
the segment count in the index commit is not reliable as it may have changed due to background merges.
=> fixed by always using the segment count determined from the file names in the snapshot instead
closes #74249
I'm not the biggest fan of my test here to be honest, but I couldn't find a way to have more fine grained control over background merges so I went with this rather brute force approach (alternative test suggestions very welcome :)). The test does however reproduce the problem reliable in 100% of runs for me.